18099 Commits (d0833fdae7ebb520e14db20ebd8973c5999f636e)

Author	SHA1	Message	Date
Fujii Masao	b2ff2a0b52	doc: Clarify INCLUDING COMMENTS behavior in CREATE TABLE LIKE. ... The documentation for the INCLUDING COMMENTS option of the LIKE clause in CREATE TABLE was inaccurate and incomplete. It stated that comments for copied columns, constraints, and indexes are copied, but regarding comments on constraints in reality only comments on CHECK and NOT NULL constraints are copied; comments on other constraints (such as primary keys) are not. In addition, comments on extended statistics are copied, but this was not documented. The CREATE FOREIGN TABLE documentation had a similar omission: comments on extended statistics are also copied, but this was not mentioned. This commit updates the documentation to clarify the actual behavior. The CREATE TABLE reference now specifies that comments on copied columns, CHECK constraints, NOT NULL constraints, indexes, and extended statistics are copied. The CREATE FOREIGN TABLE reference now notes that comments on extended statistics are copied as well. Backpatch to all supported versions. Documentation updates related to CREATE FOREIGN TABLE LIKE and NOT NULL constraint comment copying are not applied to v17 and earlier, since those features were introduced in v18. Author: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Matheus Alcantara <matheusssilv97@gmail.com> Discussion: https://postgr.es/m/CAHGQGwHSOSGcaYDvHF8EYCUCfGPjbRwGFsJ23cx5KbJ1X6JouQ@mail.gmail.com Backpatch-through: 14	3 months ago
Peter Eisentraut	dea0812cda	doc: Add link targets to CREATE/ALTER FOREIGN TABLE reference pages ... This adds IDs to create_foreign_table.sgml's and alter_foreign_table.sgml's <varlistentry> and <refsect1>, similar to other reference pages. Author: jian he <jian.universality@gmail.com> Reviewed-by: Quan Zongliang <quanzongliang@yeah.net> Reviewed-by: wenhui qiu <qiuwenhuifx@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/CACJufxE6fW2jFAyTFWEYdUSDP%3D9P2yYerdksPTgxqDM4DZvvvw%40mail.gmail.com	3 months ago
Peter Eisentraut	f80bedd52b	Allow ALTER COLUMN SET EXPRESSION on virtual columns with CHECK constraints ... Previously, changing the generation expression of a virtual column was prohibited if the column was referenced by a CHECK constraint. This lifts that restriction. RememberAllDependentForRebuilding within ATExecSetExpression will rebuild all the dependent constraints, later ATPostAlterTypeCleanup queues the required AlterTableStmt operations for ALTER TABLE Phase 3 execution. Overall, ALTER COLUMN SET EXPRESSION on virtual columns may require scanning the table to re-verify any associated CHECK constraints, but it does not require a table rewrite in ALTER TABLE Phase 3. Author: jian he <jian.universality@gmail.com> Reviewed-by: Matheus Alcantara <matheusssilv97@gmail.com> Discussion: https://postgr.es/m/CACJufxH3VETr7orF5rW29GnDk3n1wWbOE3WdkHYd3iPGrQ9E_A@mail.gmail.com	3 months ago
Michael Paquier	e2f3d82f89	doc: Adjust some markups on pg_waldump page ... Author: Peter Smith <smithpb2250@gmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> Discussion: https://postgr.es/m/CAHut+PuuPps9bUPvouU5dH=tOTiF8QBzQox5O7DqXeOFdda79Q@mail.gmail.com	3 months ago
Nathan Bossart	d981976027	Allow pg_{read,write}_all_data to access large objects. ... Since the initial goal of pg_read_all_data was to be able to run pg_dump as a non-superuser without explicitly granting access to every object, it follows that it should allow reading all large objects. For consistency, pg_write_all_data should allow writing all large objects, too. Author: Nitin Motiani <nitinmotiani@google.com> Co-authored-by: Nathan Bossart <nathandbossart@gmail.com> Reviewed-by: Dilip Kumar <dilipbalaut@gmail.com> Discussion: https://postgr.es/m/CAH5HC96dxAEvP78s1-JK_nDABH5c4w2MDfyx4vEWxBEfofGWsw%40mail.gmail.com	3 months ago
Jacob Champion	4966bd3ed9	libpq: Grease the protocol by default ... Send PG_PROTOCOL_GREASE and _pq_.test_protocol_negotiation, which were introduced in commit d8d7c5dc8, by default, and fail the connection if the server attempts to claim support for them. The hope is to provide feedback to noncompliant implementations and gain confidence in our ability to advance the protocol. (See the other commit for details.) To help end users navigate the situation, a link to our documentation that explains the behavior is displayed. We append this to the error message when the NegotiateProtocolVersion response is incorrect, or when the peer sends an error during startup that appears to be grease- related. It's still possible for users to connect to servers that don't support protocol negotiation, by adding max_protocol_version=3.0 to their connection strings. Only the default connection behavior is impacted. This commit is tracked as a PG19 open item and will be reverted before RC1. (The implementation here doesn't handle negotiation with later server versions, so it can't be released into the wild as a five-year-supported feature. But an improved implementation might be able to do so, in the future...) Author: Jelte Fennema-Nio <postgres@jeltef.nl> Co-authored-by: Jacob Champion <jacob.champion@enterprisedb.com> Discussion: https://postgr.es/m/DDPR5BPWH1RJ.1LWAK6QAURVAY%40jeltef.nl	3 months ago
Tom Lane	4a1b05caa5	Restore AIX support. ... The concerns that led us to remove AIX support in commit 0b16bb877 have now been alleviated: 1. IBM has stepped forward to provide support, including buildfarm animal(s). 2. AIX 7.2 and later seem to be fine with large pg_attribute_aligned requirements. Since 7.1 is now EOL anyway, we can just cease to support it. 3. Tossing xlc support overboard seems okay as well. It's a bit sad to drop one of the few remaining non-gcc-alike compilers, but working around xlc's bugs and idiosyncrasies doesn't seem justified by the theoretical portability benefits. 4. Likewise, we can stop supporting 32-bit AIX builds. This is not so much about whether we could build such executables as that they're too much of a pain to manage in the field, due to limited address space available for dynamic library loading. 5. We hit on a way to manage catalog column alignment that doesn't require continuing developer effort (see commit ecae09725). Hence, this commit reverts 0b16bb877 and some follow-on commits such as e6bb491bf, except for not putting back XLC support nor the changes related to catalog column alignment. Some other notable changes from the way things were in v16: Prefer unnamed POSIX semaphores on AIX, rather than the default choice of SysV semaphores. Include /opt/freeware/lib in -Wl,-blibpath, even when it is not mentioned anywhere in LDFLAGS. Remove platform-specific adjustment of MEMSET_LOOP_LIMIT; maybe that's still the right thing, but it really ought to be re-tested. Silence compiler warnings related to getpeereid(), wcstombs_l(), and PAM conversation procs. Accept "libpythonXXX.a" as an okay name for the Python shared library (but only on AIX!). Author: Aditya Kamath <Aditya.Kamath1@ibm.com> Author: Srirama Kucherlapati <sriram.rk@in.ibm.com> Co-authored-by: Peter Eisentraut <peter@eisentraut.org> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/CY5PR11MB63928CC05906F27FB10D74D0FD322@CY5PR11MB6392.namprd11.prod.outlook.com	3 months ago
Nathan Bossart	bc60ee8606	Warn upon successful MD5 password authentication. ... This uses the "connection warning" infrastructure introduced by commit 1d92e0c2cc to emit a WARNING when an MD5 password is used to authenticate. MD5 password support was marked as deprecated in v18 and will be removed in a future release of Postgres. These warnings are on by default but can be turned off via the existing md5_password_warnings parameter. Reviewed-by: Andreas Karlsson <andreas@proxel.se> Reviewed-by: Xiangyu Liang <liangxiangyu_2013@163.com> Discussion: https://postgr.es/m/aYzeAYEbodkkg5e-%40nathan	3 months ago
Peter Eisentraut	78727dcba3	meson: allow disabling building/installation of static libraries. ... We now support the common meson option -Ddefault_library, with values 'both' (the default), 'shared' (install only shared libraries), and 'static' (install only static libraries). The 'static' choice doesn't actually work, since psql and other programs insist on linking to the shared version of libpq, but it's there pro-forma. It could be built out if we really wanted, but since we have never supported the equivalent in the autoconf build system, there doesn't appear to be an urgent need. With an eye to re-supporting AIX, the internal implementation distinguishes whether to install libpgport.a and other static-only libraries from whether to build/install the static variant of libraries that we can build both ways. This detail isn't exposed as a meson option, though it could be if there's demand. The Cirrus CI task SanityCheck now uses -Ddefault_library=shared to save a little bit of build time (and to test this option). Author: Peter Eisentraut <peter@eisentraut.org> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/e8aa97db-872b-4087-b073-f296baae948d@eisentraut.org	3 months ago
Michael Paquier	ee46584884	doc: Add section "Options" for pg_controldata ... Adding this section brings consistency with the pages of other tools, potentially easing the introduction of new options in the future as these are now showing in the shape of a list. Author: Peter Smith <smithpb2250@gmail.com> Reviewed-by: Andreas Karlsson <andreas@proxel.se> Discussion: https://postgr.es/m/CAHut+PtSF5AW3DHpYA-_muDLms2xBUzHpd545snVj8vFpmsmGg@mail.gmail.com	3 months ago
Michael Paquier	4476106c65	doc: Add description of "filename" for pg_walsummary ... This command requires an input file (WAL summary file), that has to be specified without an option name. The shape of the command and how to use this parameter is implied in its synopsis. However, this page lacked a description of the parameter. Listing parameters that do not require an option is a common practice across the docs. See for example pg_dump, pg_restore, etc. Author: Peter Smith <smithpb2250@gmail.com> Discussion: https://postgr.es/m/CAHut+PtbQi8Dw_0upS9dd=Oh9OqfOdAo=0_DOKG=YSRT_a+0Fw@mail.gmail.com	3 months ago
Fujii Masao	fb80f388f4	Add per-subscription wal_receiver_timeout setting. ... This commit allows setting wal_receiver_timeout per subscription using the CREATE SUBSCRIPTION and ALTER SUBSCRIPTION commands. The value is stored in the subwalrcvtimeout column of the pg_subscription catalog. When set, this value overrides the global wal_receiver_timeout for the subscription's apply worker. The default is -1, which means the global setting (from the server configuration, command line, role, or database) remains in effect. This feature is useful for configuring different timeout values for each subscription, especially when connecting to multiple publisher servers, to improve failure detection. Bump catalog version. Author: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Japin Li <japinli@hotmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Discussion: https://postgr.es/m/a1414b64-bf58-43a6-8494-9704975a41e9@oss.nttdata.com	4 months ago
Fujii Masao	8a6af3ad08	Make GUC wal_receiver_timeout user-settable. ... When multiple subscribers connect to different publisher servers, it can be useful to set different wal_receiver_timeout values for each connection to better detect failures. However, previously this wasn't possible, which limited flexibility in managing subscriptions. This commit changes wal_receiver_timeout to be user-settable, allowing different values to be assigned using ALTER ROLE SET for each subscription owner. This effectively enables per-subscription configuration. Author: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Japin Li <japinli@hotmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Discussion: https://postgr.es/m/a1414b64-bf58-43a6-8494-9704975a41e9@oss.nttdata.com	4 months ago
Tom Lane	759b03b24c	Simplify creation of built-in functions with default arguments. ... Up to now, to create such a function, one had to make a pg_proc.dat entry and then overwrite it with a CREATE OR REPLACE command in system_functions.sql. That's error-prone (cf. bug #19409) and results in leaving dead rows in the initial contents of pg_proc. Manual maintenance of pg_node_tree strings seems entirely impractical, and parsing expressions during bootstrap would be extremely difficult as well. But Andres Freund observed that all the current use-cases are simple constants, and building a Const node is well within the capabilities of bootstrap mode. So this patch invents a special case: if bootstrap mode is asked to ingest a non-null value for pg_proc.proargdefaults (which would otherwise fail in pg_node_tree_in), it parses the value as an array literal and then feeds the element strings to the input functions for the corresponding parameter types. Then we can build a suitable pg_node_tree string with just a few more lines of code. This allows removing all the system_functions.sql entries that are just there to set up default arguments, replacing them with proargdefaults fields in pg_proc.dat entries. The old technique remains available in case someone needs a non-constant default. The initial contents of pg_proc are demonstrably the same after this patch, except that (1) json_strip_nulls and jsonb_strip_nulls now have the correct provolatile setting, as per bug #19409; (2) pg_terminate_backend, make_interval, and drandom_normal now have defaults that don't include a type coercion, which is how they should have been all along. In passing, remove some unused entries from bootstrap.c's TypInfo[] array. I had to add some new ones because we'll now need an entry for each default-possessing system function parameter, but we shouldn't carry more than we need there; it's just a maintenance gotcha. Bug: #19409 Reported-by: Lucio Chiessi <lucio.chiessi@trustly.com> Author: Tom Lane <tgl@sss.pgh.pa.us> Author: Andrew Dunstan <andrew@dunslane.net> Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/183292bb-4891-4c96-a3ca-e78b5e0e1358@dunslane.net Discussion: https://postgr.es/m/19409-e16cd2605e59a4af@postgresql.org	4 months ago
Heikki Linnakangas	d62dca3b29	Use standard die() handler for SIGTERM in bgworkers ... The previous default bgworker_die() signal would exit with elog(FATAL) directly from the signal handler. That could cause deadlocks or crashes if the signal handler runs while we're e.g holding a spinlock or in the middle of a memory allocation. All the built-in background workers overrode that to use the normal die() handler and CHECK_FOR_INTERRUPTS(). Let's make that the default for all background workers. Some extensions relying on the old behavior might need to adapt, but the new default is much safer and is the right thing to do for most background workers. Reviewed-by: Nathan Bossart <nathandbossart@gmail.com> Reviewed-by: Kirill Reshke <reshkekirill@gmail.com> Discussion: https://www.postgresql.org/message-id/5238fe45-e486-4c62-a7f3-c7d8d416e812@iki.fi	4 months ago
Daniel Gustafsson	db93988ab0	doc: Add note to ssl_group config on X25519 and FIPS ... The X25519 curve is not allowed when OpenSSL is configured for FIPS mode, so add a note to the documentation that the default setting must be altered for such setups. Author: Daniel Gustafsson <daniel@yesql.se> Reported-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/3521653.1770666093@sss.pgh.pa.us	4 months ago
Daniel Gustafsson	aa082bed0b	doc: Mention PASSING support for jsonpath variables ... Commit dfd79e2d added a TODO comment to update this paragraph when support for PASSING was added. Commit 6185c9737c added PASSING but missed resolving this TODO. Fix by expanding the paragraph with a reference to PASSING. Author: Aditya Gollamudi <adigollamudi@gmail.com> Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Discussion: https://postgr.es/m/20260117051406.sx6pss4ryirn2x4v@pgs	4 months ago
Daniel Gustafsson	4469fe1761	doc: Update docs images README with required ditaa version ... The URL for Ditaa linked to the old Sourceforge version which is too old for what we need, the fork over on Github is the correct version to use for re-generating the SVG files for the docs. The required Ditaa version is 0.11.0 as it when SVG support as added. Running the version found on Sourceforge produce the error below: $ ditaa -E -S --svg in.txt out.txt Unrecognized option: --svg usage: ditaa <INPFILE> [OUTFILE] [-A] [-b <BACKGROUND>] [-d] [-E] [-e <ENCODING>] [-h] [--help] [-o] [-r] [-S] [-s <SCALE>] [-T] [-t <TABS>] [-v] [-W] While there, also mention that meson rules exists for building images. Author: Nazir Bilal Yavuz <byavuz81@gmail.com> Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Reviewed-by: Paul A Jungwirth <pj@illuminatedcomputing.com> Discussion: https://postgr.es/m/CAN55FZ2O-23xERF2NYcvv9DM_1c9T16y6mi3vyP=O1iuXS0ASA@mail.gmail.com	4 months ago
Daniel Gustafsson	4ec0e75afd	meson: Add target for generating docs images ... This adds an 'images' target to the meson build system in order to be able to regenerate the images used in the docs. Author: Nazir Bilal Yavuz <byavuz81@gmail.com> Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Reported-by: Daniel Gustafsson <daniel@yesql.se> Discussion: https://postgr.es/m/CAN55FZ0c0Tcjx9=e-YibWGHa1-xmdV63p=THH4YYznz+pYcfig@mail.gmail.com	4 months ago
Dean Rasheed	88327092ff	Add support for INSERT ... ON CONFLICT DO SELECT. ... This adds a new ON CONFLICT action DO SELECT [FOR UPDATE/SHARE], which returns the pre-existing rows when conflicts are detected. The INSERT statement must have a RETURNING clause, when DO SELECT is specified. The optional FOR UPDATE/SHARE clause allows the rows to be locked before they are are returned. As with a DO UPDATE conflict action, an optional WHERE clause may be used to prevent rows from being selected for return (but as with a DO UPDATE action, rows filtered out by the WHERE clause are still locked). Bumps catversion as stored rules change. Author: Andreas Karlsson <andreas@proxel.se> Author: Marko Tiikkaja <marko@joh.to> Author: Viktor Holmberg <v@viktorh.net> Reviewed-by: Joel Jacobson <joel@compiler.org> Reviewed-by: Kirill Reshke <reshkekirill@gmail.com> Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com> Reviewed-by: Jian He <jian.universality@gmail.com> Discussion: https://postgr.es/m/d631b406-13b7-433e-8c0b-c6040c4b4663@Spark Discussion: https://postgr.es/m/5fca222d-62ae-4a2f-9fcb-0eca56277094@Spark Discussion: https://postgr.es/m/2b5db2e6-8ece-44d0-9890-f256fdca9f7e@proxel.se Discussion: https://postgr.es/m/CAL9smLCdV-v3KgOJX3mU19FYK82N7yzqJj2HAwWX70E=P98kgQ@mail.gmail.com	4 months ago
Nathan Bossart	1d92e0c2cc	Add password expiration warnings. ... This commit adds a new parameter called password_expiration_warning_threshold that controls when the server begins emitting imminent-password-expiration warnings upon successful password authentication. By default, this parameter is set to 7 days, but this functionality can be disabled by setting it to 0. This patch also introduces a new "connection warning" infrastructure that can be reused elsewhere. For example, we may want to warn about the use of MD5 passwords for a couple of releases before removing MD5 password support. Author: Gilles Darold <gilles@darold.net> Co-authored-by: Nathan Bossart <nathandbossart@gmail.com> Reviewed-by: Japin Li <japinli@hotmail.com> Reviewed-by: songjinzhou <tsinghualucky912@foxmail.com> Reviewed-by: liu xiaohui <liuxh.zj.cn@gmail.com> Reviewed-by: Yuefei Shi <shiyuefei1004@gmail.com> Reviewed-by: Steven Niu <niushiji@gmail.com> Reviewed-by: Soumya S Murali <soumyamurali.work@gmail.com> Reviewed-by: Euler Taveira <euler@eulerto.com> Reviewed-by: Zsolt Parragi <zsolt.parragi@percona.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Greg Sabino Mullane <htamfids@gmail.com> Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Discussion: https://postgr.es/m/129bcfbf-47a6-e58a-190a-62fc21a17d03%40migops.com	4 months ago
Álvaro Herrera	1efdd7cc63	Cleanup for log_min_messages changes in 38e0190ced ... * Remove an unused variable * Use "default log level" consistently (instead of "generic") * Keep the process types in alphabetical order (missed one place in the SGML docs) * Since log_min_messages type was changed from enum to string, it is a good idea to add single quotes when printing it out. Otherwise it fails if the user copies and pastes from the SHOW output to SET, except in the simplest case. Using single quotes reduces confusion. * Use lowercase string for the burned-in default value, to keep the same output as previous versions. Author: Euler Taveira <euler@eulerto.com> Author: Man Zeng <zengman@halodbtech.com> Author: Noriyoshi Shinoda <noriyoshi.shinoda@hpe.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Discussion: https://postgr.es/m/202602091250.genyflm2d5dw@alvherre.pgsql	4 months ago
Dean Rasheed	bc953bf523	doc: Mention all SELECT privileges required by INSERT ... ON CONFLICT. ... On the INSERT page, mention that SELECT privileges are also required for any columns mentioned in the arbiter clause, including those referred to by the constraint, and clarify that this applies to all forms of ON CONFLICT, not just ON CONFLICT DO UPDATE. Author: Dean Rasheed <dean.a.rasheed@gmail.com> Reviewed-by: Viktor Holmberg <v@viktorh.net> Discussion: https://postgr.es/m/CAEZATCXGwMQ+x00YY9XYG46T0kCajH=21QaYL9Xatz0dLKii+g@mail.gmail.com Backpatch-through: 14	4 months ago
Dean Rasheed	227a6ea657	doc: Clarify RLS policies applied for ON CONFLICT DO NOTHING. ... On the CREATE POLICY page, the description of per-command policies stated that SELECT policies are applied when an INSERT has an ON CONFLICT DO NOTHING clause. However, that is only the case if it includes an arbiter clause, so clarify that. While at it, also clarify the comment in the regression tests that cover this. Author: Dean Rasheed <dean.a.rasheed@gmail.com> Reviewed-by: Viktor Holmberg <v@viktorh.net> Discussion: https://postgr.es/m/CAEZATCXGwMQ+x00YY9XYG46T0kCajH=21QaYL9Xatz0dLKii+g@mail.gmail.com Backpatch-through: 14	4 months ago
Michael Paquier	9181c870ba	Improve type handling of varlena structures ... This commit changes the definition of varlena to a typedef, so as it becomes possible to remove "struct" markers from various declarations in the code base. Historically, "struct" markers are not the project style for variable declarations, so this update simplifies the code and makes it more consistent across the board. This change has an impact on the following structures, simplifying declarations using them: - varlena - varatt_indirect - varatt_external This cleanup has come up in a different path set that played with TOAST and varatt.h, independently worth doing on its own. Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de> Reviewed-by: Andreas Karlsson <andreas@proxel.se> Reviewed-by: Shinya Kato <shinya11.kato@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Discussion: https://postgr.es/m/aW8xvVbovdhyI4yo@paquier.xyz	4 months ago
Michael Paquier	307447e6db	Add information about range type stats to pg_stats_ext_exprs ... This commit adds three attributes to the system view pg_stats_ext_exprs, whose data can exist when involving a range type in an expression: range_length_histogram range_empty_frac range_bounds_histogram These statistics fields exist since 918eee0c49, and have become viewable in pg_stats later in bc3c8db8ae. This puts the definition of pg_stats_ext_exprs on par with pg_stats. This issue has showed up during the discussion about the restore of extended statistics for expressions, so as it becomes possible to query the stats data to restore from the catalogs. Having access to this data is useful on its own, without the restore part. Some documentation and some tests are added, written by me. Corey has authored the part in system_views.sql. Bump catalog version. Author: Corey Huinker <corey.huinker@gmail.com> Co-authored-by: Michael Paquier <michael@paquier.xyz> Discussion: https://postgr.es/m/aYmCUx9VvrKiZQLL@paquier.xyz	4 months ago
Álvaro Herrera	38e0190ced	Allow log_min_messages to be set per process type ... Change log_min_messages from being a single element to a comma-separated list of type:level elements, with 'type' representing a process type, and 'level' being a log level to use for that type of process. The list must also have a freestanding level specification which is used for process types not listed, which convenientely makes the whole thing backwards-compatible. Some choices made here could be contested; for instance, we use the process type `backend` to affect regular backends as well as dead-end backends and the standalone backend, and `autovacuum` means both the launcher and the workers. I think it's largely sensible though, and it can easily be tweaked if desired. Author: Euler Taveira <euler@eulerto.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Japin Li <japinli@hotmail.com> Reviewed-by: Tan Yang <332696245@qq.com> Discussion: https://postgr.es/m/e85c6671-1600-4112-8887-f97a8a5d07b2@app.fastmail.com	4 months ago
Jacob Champion	d8d7c5dc8f	libpq: Prepare for protocol grease during 19beta ... The main reason that libpq doesn't request protocol version 3.2 by default is because other proxy/server implementations don't implement the negotiation. This is a bit of a chicken-and-egg problem: We don't bump the default version that libpq requests, but other implementations may not be incentivized to implement version negotiation if their users never run into issues. One established practice to combat this is to flip Postel's Law on its head, by sending parameters that the server cannot possibly support. If the server fails the handshake instead of correctly negotiating, then the problem is surfaced naturally. If the server instead claims to support the bogus parameters, then we fail the connection to make the lie obvious. This is called "grease" (or "greasing"), after the GREASE mechanism in TLS that popularized the concept: https://www.rfc-editor.org/rfc/rfc8701.html This patch reserves 3.9999 as an explicitly unsupported protocol version number and `_pq_.test_protocol_negotiation` as an explicitly unsupported protocol extension. A later commit will send these by default in order to stress-test the ecosystem during the beta period; that commit will then be reverted before 19 RC1, so that we can decide what to do with whatever data has been gathered. The _pq_.test_protocol_negotiation change here is intentionally docs- only: after its implementation is reverted, the parameter should remain reserved. Extracted/adapted from a patch by Jelte Fennema-Nio. Author: Jelte Fennema-Nio <postgres@jeltef.nl> Co-authored-by: Jacob Champion <jacob.champion@enterprisedb.com> Discussion: https://postgr.es/m/DDPR5BPWH1RJ.1LWAK6QAURVAY%40jeltef.nl	4 months ago
Jacob Champion	e3d37853ec	doc: Expand upon protocol versions and extensions ... First, split the Protocol Versions table in two, and lead with the list of versions that are supported today. Reserved and unsupported version numbers go into the second table. Second, in anticipation of a new (reserved) protocol extension, document the extension negotiation process alongside version negotiation, and add the corresponding tables for future extension parameter registrations. Reviewed-by: Jelte Fennema-Nio <postgres@jeltef.nl> Reviewed-by: David G. Johnston <david.g.johnston@gmail.com> Discussion: https://postgr.es/m/DDPR5BPWH1RJ.1LWAK6QAURVAY%40jeltef.nl	4 months ago
Thomas Munro	f94e9141a0	Add file_extend_method=posix_fallocate,write_zeros. ... Provide a way to disable the use of posix_fallocate() for relation files. It was introduced by commit 4d330a61bb. The new setting file_extend_method=write_zeros can be used as a workaround for problems reported from the field: * BTRFS compression is disabled by the use of posix_fallocate() * XFS could produce spurious ENOSPC errors in some Linux kernel versions, though that problem is reported to have been fixed The default is file_extend_method=posix_fallocate if available, as before. The write_zeros option is similar to PostgreSQL < 16, except that now it's multi-block. Backpatch-through: 16 Reviewed-by: Jakub Wartak <jakub.wartak@enterprisedb.com> Reported-by: Dimitrios Apostolou <jimis@gmx.net> Discussion: https://postgr.es/m/b1843124-fd22-e279-a31f-252dffb6fbf2%40gmx.net	4 months ago
Fujii Masao	e35add48cc	doc: Move synchronized_standby_slots to "Primary Server" section. ... synchronized_standby_slots is defined in guc_parameter.dat as part of the REPLICATION_PRIMARY group and is listed under the "Primary Server" section in postgresql.conf.sample. However, in the documentation its description was previously placed under the "Sending Servers" section. Since synchronized_standby_slots only takes effect on the primary server, this commit moves its documentation to the "Primary Server" section to match its behavior and other references. Backpatch to v17 where synchronized_standby_slots was added. Author: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Shinya Kato <shinya11.kato@gmail.com> Discussion: https://postgr.es/m/CAHGQGwE_LwgXgCrqd08OFteJqdERiF3noqOKu2vt7Kjk4vMiGg@mail.gmail.com Backpatch-through: 17	4 months ago
Michael Paquier	3c5ec35dea	oid2name: Add relation path to the information provided by -x/--extended ... This affects two command patterns, showing information about relations: * oid2name -x -d DBNAME, applying to all relations on a database. * oid2name -x -d DBNAME -t TABNAME [-t ..], applying to a subset of defined relations on a database. The relative path of a relation is added to the information provided, using pg_relation_filepath(). Author: David Bidoc <dcbidoc@gmail.com> Reviewed-by: Laurenz Albe <laurenz.albe@cybertec.at> Reviewed-by: Guillaume Lelarge <guillaume.lelarge@dalibo.com> Reviewed-by: Euler Taveira <euler@eulerto.com> Reviewed-by: Mark Wong <markwkm@gmail.com> Discussion: https://postgr.es/m/CABour1v2CU1wjjoM86wAFyezJQ3-+ncH43zY1f1uXeVojVN8Ow@mail.gmail.com	4 months ago
Álvaro Herrera	78bf28e3bf	Docs: consolidate dependency notes in pg_dump and pg_restore ... The pg_dump documentation had repetitive notes for the --schema, --table, and --extension switches, noting that dependent database objects are not automatically included in the dump. This commit removes these notes and replaces them with a consolidated paragraph in the "Notes" section. pg_restore had a similar note for -t but lacked one for -n; do likewise. Also, add a note to --extension in pg_dump to note that ancillary files (such as shared libraries and control files) are not included in the dump and must be present on the destination system. Author: Florents Tselai <florents.tselai@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/284C4D55-4F90-4AA0-84C8-1E6A28DDF271@gmail.com	4 months ago
Fujii Masao	dddbbc253b	psql: Add %i prompt escape to indicate hot standby status. ... This commit introduces a new prompt escape %i for psql, which shows whether the connected server is operating in hot standby mode. It expands to standby if the server reports in_hot_standby = on, and primary otherwise. This is useful for distinguishing standby servers from primary ones at a glance, especially when working with multiple connections in replicated environments where libpq's multi-host connection strings are used. Author: Jim Jones <jim.jones@uni-muenster.de> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Greg Sabino Mullane <htamfids@gmail.com> Reviewed-by: Srinath Reddy Sadipiralla <srinath2133@gmail.com> Reviewed-by: Nathan Bossart <nathandbossart@gmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Andreas Karlsson <andreas@proxel.se> Discussion: https://www.postgresql.org/message-id/flat/016f6738-f9a9-4e98-bb5a-e1e4b9591d46@uni-muenster.de	4 months ago
Michael Paquier	efbebb4e85	Add support for "mcv" in pg_restore_extended_stats() ... This commit adds support for the restore of extended statistics of the kind "mcv", aka most-common values. This format is different from n_distinct and dependencies stat types in that it is the combination of three of the four different arrays from the pg_stats_ext view which in turn require three different input parameters on pg_restore_extended_statistics(). These are translated into three input arguments for the function: - "most_common_vals", acting as a leader of the others. It is a 2-dimension array, that includes the common values. - "most_common_freqs", 1-dimension array of float8[], with a number of elements that has to match with "most_common_vals". - "most_common_base_freqs", 1-dimension array of float8[], with a number of elements that has to match with "most_common_vals". All three arrays are required to achieve the restore of this type of extended statistics (if "most_common_vals" happens to be NULL in the catalogs, the rest is NULL by design). Note that "most_common_val_nulls" is not required in input, its data is rebuilt from the decomposition of the "most_common_vals" array based on its text[] representation. The initial versions of the patch provided this option in input, but we do not require it and it simplifies a lot the result. Support in pg_dump is added down to v13 which is where the support for this type of extended statistics has been added, when --statistics is used. This means that upgrade and dumps can restore extended statistics data transparently, like "dependencies", "ndistinct", attribute and relation statistics. For MCV, the values are directly queried from the relevant catalogs. Author: Corey Huinker <corey.huinker@gmail.com> Co-authored-by: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://postgr.es/m/CADkLM=dpz3KFnqP-dgJ-zvRvtjsa8UZv8wDAQdqho=qN3kX0Zg@mail.gmail.com	4 months ago
Masahiko Sawada	1fdbca159e	Standardize replication origin naming to use "ReplOrigin". ... The replication origin code was using inconsistent naming conventions. Functions were typically prefixed with 'replorigin', while typedefs and constants used "RepOrigin". This commit unifies the naming convention by renaming RepOriginId to ReplOriginId. Reviewed-by: Chao Li <li.evan.chao@gmail.com> Discussion: https://postgr.es/m/CAD21AoBDgm3hDqUZ+nqu=ViHmkCnJBuJyaxG_yvv27BAi2zBmQ@mail.gmail.com	4 months ago
Michael Paquier	302879bd68	Add support for "dependencies" in pg_restore_extended_stats() ... This commit adds support for the restore of extended statistics of the kind "dependencies", for the following input data: [{"attributes": [2], "dependency": 3, "degree": 1.000000}, {"attributes": [3], "dependency": 2, "degree": 1.000000}] This relies on the existing routines of "dependencies" to cross-check the input data with the definition of the extended statistics objects for the attribute numbers. An input argument of type "pg_dependencies" is required for this new option. Thanks to the work done in 0e80f3f88d for the restore function and e1405aa5e3 for the input handling of data type pg_dependencies, this addition is straight-forward. This will be used so as it is possible to transfer these statistics across dumps and upgrades, removing the need for a post-operation ANALYZE for these kinds of statistics. Author: Corey Huinker <corey.huinker@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://postgr.es/m/CADkLM=dpz3KFnqP-dgJ-zvRvtjsa8UZv8wDAQdqho=qN3kX0Zg@mail.gmail.com	4 months ago
Fujii Masao	33a92632b7	doc: Clarify that \d and \d+ output lists are illustrative, not exhaustive. ... The psql documentation for the \d and \d+ meta-commands lists objects that may be shown, but previously the wording could be read as exhaustive even though additional objects can also appear in the output. This commit clarifies the description by adding phrasing such as "for example" or "such as", making it clear that the listed objects are illustrative rather than a complete list. While the change is small, it helps avoid potential user confusion. As this is a documentation clarification rather than a bug fix, it is not backpatched. Author: Peter Smith <smithpb2250@gmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Andreas Karlsson <andreas@proxel.se> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/CAHut+Pt1DBtaUqfJftkkaQLJJJenYJBtb6Ec6s6vu82KEMh46A@mail.gmail.com	4 months ago
Michael Paquier	0e80f3f88d	Add pg_restore_extended_stats() ... This function closely mirror its relation and attribute counterparts, but for extended statistics (i.e. CREATE STATISTICS) objects, being able to restore extended statistics for an extended stats object. Like the other functions, the goal of this feature is to ease the dump or upgrade of clusters so as ANALYZE would not be required anymore after these operations, stats being directly loaded into the target cluster without any post-dump/upgrade computation. The caller of this function needs the following arguments for the extended stats to restore: - The name of the relation. - The schema name of the relation. - The name of the extended stats object. - The schema name of the extended stats object. - If the stats are inherited or not. - One or more extended stats kind with its data. This commit adds only support for the restore of the extended statistics kind "n_distinct", building the basic infrastructure for the restore of more extended statistics kinds in follow-up commits, including MVC and dependencies. The support for "n_distinct" is eased in this commit thanks to the previous work done particularly in commits 1f927cce44 and 44eba8f06e, that have added the input function for the type pg_ndistinct, used as data type in input of this new restore function. Bump catalog version. Author: Corey Huinker <corey.huinker@gmail.com> Co-authored-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Discussion: https://postgr.es/m/CADkLM=dpz3KFnqP-dgJ-zvRvtjsa8UZv8wDAQdqho=qN3kX0Zg@mail.gmail.com	4 months ago
Michael Paquier	a36164e746	Add WALRCV_CONNECTING state to the WAL receiver ... Previously, a WAL receiver freshly started would set its state to WALRCV_STREAMING immediately at startup, before actually establishing a replication connection. This commit introduces a new state called WALRCV_CONNECTING, which is the state used when the WAL receiver freshly starts, or when a restart is requested, with a switch to WALRCV_STREAMING once the connection to the upstream server has been established with COPY_BOTH, meaning that the WAL receiver is ready to stream changes. This change is useful for monitoring purposes, especially in environments with a high latency where a connection could take some time to be established, giving some room between the [re]start phase and the streaming activity. From the point of view of the startup process, that flips the shared memory state of the WAL receiver when it needs to be stopped, the existing WALRCV_STREAMING and the new WALRCV_CONNECTING states have the same semantics: the WAL receiver has started and it can be stopped. Based on an initial suggestion from Noah Misch, with some input from me about the design. Author: Xuneng Zhou <xunengzhou@gmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Rahila Syed <rahilasyed90@gmail.com> Discussion: https://postgr.es/m/CABPTF7VQ5tGOSG5TS-Cg+Fb8gLCGFzxJ_eX4qg+WZ3ZPt=FtwQ@mail.gmail.com	4 months ago
Peter Eisentraut	c257ba8397	Record range constructor functions in pg_range ... When a range type is created, several construction functions are also created, two for the range type and three for the multirange type. These have an internal dependency, so they "belong" to the range type. But there was no way to identify those functions when given a range type. An upcoming patch needs access to the two- or possibly the three-argument range constructor function for a given range type. The only way to do that would be with fragile workarounds like matching names and argument types. The correct way to do that kind of thing is to record to the links in the system catalogs. This is what this patch does, it records the OIDs of these five constructor functions in the pg_range catalog. (Currently, there is no code that makes use of this.) Reviewed-by: Paul A Jungwirth <pj@illuminatedcomputing.com> Reviewed-by: Kirill Reshke <reshkekirill@gmail.com> Discussion: https://www.postgresql.org/message-id/7d63ddfa-c735-4dfe-8c7a-4f1e2a621058%40eisentraut.org	4 months ago
Peter Eisentraut	a5b40d156e	Mark commented out code as unused ... There were many PG_GETARG_* calls, mostly around gin, gist, spgist code, that were commented out, presumably to indicate that the argument was unused and to indicate that it wasn't forgotten or miscounted. But keeping commented-out code updated with refactorings and style changes is annoying. So this commit changes them to #ifdef NOT_USED blocks, which is a style already in use. That way, at least the indentation and syntax highlighting works correctly, making some of these blocks much easier to read. An alternative would be to just delete that code, but there is some value in making unused arguments explicit, and some of this arguably serves as example code for index AM APIs. Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Reviewed-by: David Geier <geidav.pg@gmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/328e4371-9a4c-4196-9df9-1f23afc900df%40eisentraut.org	4 months ago
Michael Paquier	1a1e733b62	doc: List all the possible values of pg_stat_wal_receiver.status ... The possible values of pg_stat_wal_receiver.status have never been documented. Note that the status "stopped" will never show up in this view, hence there is no need to document it. Issue noticed while discussing a patch that aims to add a new status to WAL receiver. Author: Xuneng Zhou <xunengzhou@gmail.com> Discussion: https://postgr.es/m/CABPTF7X_Jgmyk1FBVNf3tyAOKqU55LLpLMzWkGtEAb_jQWVN=g@mail.gmail.com	4 months ago
Michael Paquier	25be5e8a33	doc: Mention pg_get_partition_constraintdef() ... All the other SQL functions reconstructing definitions or commands are listed in the documentation, except this one. Oversight in 1848b73d45. Author: Todd Liebenschutz-Jones <todd.liebenschutz-jones@starlingbank.com> Discussion: https://postgr.es/m/CAGTRfaD6uRQ9iutASDzc_iDoS25sQTLWgXTtR3ta63uwTxq6bA@mail.gmail.com Backpatch-through: 14	4 months ago
Fujii Masao	26cb14aea1	file_fdw: Support multi-line HEADER option. ... Commit bc2f348 introduced multi-line HEADER support for COPY. This commit extends this capability to file_fdw, allowing multiple header lines to be skipped. Because CREATE/ALTER FOREIGN TABLE requires option values to be single-quoted, this commit also updates defGetCopyHeaderOption() to accept integer values specified as strings for HEADER option. Author: Shinya Kato <shinya11.kato@gmail.com> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: songjinzhou <tsinghualucky912@foxmail.com> Reviewed-by: Japin Li <japinli@hotmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Discussion: https://postgr.es/m/CAOzEurT+iwC47VHPMS+uJ4WSzvOLPsZ2F2_wopm8M7O+CZa3Xw@mail.gmail.com	4 months ago
Tom Lane	4576208454	Force standard_conforming_strings to always be ON. ... Continuing to support this backwards-compatibility feature has nontrivial costs; in particular it is potentially a security hazard if an application somehow gets confused about which setting the server is using. We changed the default to ON fifteen years ago, which seems like enough time for applications to have adapted. Let's remove support for the legacy string syntax. We should not remove the GUC altogether, since client-side code will still test it, pg_dump scripts will attempt to set it to ON, etc. Instead, just prevent it from being set to OFF. There is precedent for this approach (see commit de66987ad). This patch does remove the related GUC escape_string_warning, however. That setting does nothing when standard_conforming_strings is on, so it's now useless. We could leave it in place as a do-nothing setting to avoid breaking clients that still set it, if there are any. But it seems likely that any such client is also trying to turn off standard_conforming_strings, so it'll need work anyway. The client-side changes in this patch are pretty minimal, because even though we are dropping the server's support, most of our clients still need to be able to talk to older server versions. We could remove dead client code only once we disclaim compatibility with pre-v19 servers, which is surely years away. One change of note is that pg_dump/pg_dumpall now set standard_conforming_strings = on in their source session, rather than accepting the source server's default. This ensures that literals in view definitions and such will be printed in a way that's acceptable to v19+. In particular, pg_upgrade will work transparently even if the source installation has standard_conforming_strings = off. (However, pg_restore will behave the same as before if given an archive file containing standard_conforming_strings = off. Such an archive will not be safely restorable into v19+, but we shouldn't break the ability to extract valid data from it for use with an older server.) Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/3279216.1767072538@sss.pgh.pa.us	4 months ago
Amit Kapila	48efefa6ca	Improve errdetail for logical replication conflict messages. ... This change enhances the clarity and usefulness of error detail messages generated during logical replication conflicts. The following improvements have been made: 1. Eliminate redundant output: Avoid printing duplicate remote row and replica identity values for the multiple_unique_conflicts conflict type. 2. Improve message structure: Append tuple values directly to the main error message, separated by a colon (:), for better readability. 3. Simplify local row terminology: Remove the word 'existing' when referring to the local row, as this is already implied by context. 4. General code refinements: Apply miscellaneous code cleanups to improve how conflict detail messages are constructed and formatted. Author: Hayato Kuroda <kuroda.hayato@fujitsu.com> Reviewed-by: Shveta Malik <shveta.malik@gmail.com> Reviewed-by: Amit Kapila <amit.kapila16@gmail.com> Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com> Reviewed-by: Zhijie Hou <houzj.fnst@fujitsu.com> Discussion: https://postgr.es/m/CAHut+Psgkwy5-yGRJC15izecySGGysrbCszv_z93ess8XtCDOQ@mail.gmail.com	4 months ago
Bruce Momjian	2e937eeb93	doc: revert "xreflabel" used for PL/Python & libpq chapters ... This reverts d8aa21b74f, which was added for the PG 18 release notes, and adjusts the PG 18 release notes for this change. This is necessary since the "xreflabel" affected other references to these chapters. Reported-by: Robert Treat Author: Robert Treat Discussion: https://postgr.es/m/CABV9wwNEZDdp5QtrW5ut0H+MOf6U1PvrqBqmgSTgcixqk+Q73A@mail.gmail.com Backpatch-through: 18	5 months ago
Michael Paquier	d756fa1019	Add pg_clear_extended_stats() ... This function is able to clear the data associated to an extended statistics object, making things so as the object looks as newly-created. The caller of this function needs the following arguments for the extended stats to clear: - The name of the relation. - The schema name of the relation. - The name of the extended stats object. - The schema name of the extended stats object. - If the stats are inherited or not. The first two parameters are especially important to ensure a consistent lookup and ACL checks for the relation on which is based the extended stats object that will be cleared, relying first on a RangeVar lookup where permissions are checked without locking a relation, critical to prevent denial-of-service attacks when using this kind of function (see also 688dc6299a for a similar concern). The third to fifth arguments give a way to target the extended stats records to clear. This has been extracted from a larger patch by the same author, for a piece which is again useful on its own. I have rewritten large portions of it. The tests have been extended while discussing this piece, resulting on what this commit includes. The intention behind this feature is to add support for the import of extended statistics across dumps and upgrades, this change building one piece that we will be able to rely on for the rest of the changes. Bump catalog version. Author: Corey Huinker <corey.huinker@gmail.com> Co-authored-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Discussion: https://postgr.es/m/CADkLM=dpz3KFnqP-dgJ-zvRvtjsa8UZv8wDAQdqho=qN3kX0Zg@mail.gmail.com	5 months ago
Peter Eisentraut	794ba8b6a4	doc: Slightly correct advice on C/C++ linkage ... The documentation was writing that <literal>extern C</literal> should be used, but it should be <literal>extern "C"</literal>.	5 months ago