18065 Commits (master)

Author	SHA1	Message	Date
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	1 day 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	2 days 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	3 days 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 days 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 days 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	1 week 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	1 week 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	1 week 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	1 week 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	1 week 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	1 week 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	1 week 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	1 week 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	1 week 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	2 weeks 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>.	2 weeks ago
Fujii Masao	ad381d0d92	doc: Document DEFAULT option in file_fdw. ... Commit 9f8377f7a introduced the DEFAULT option for file_fdw but did not update the documentation. This commit adds the missing description of the DEFAULT option to the file_fdw documentation. Backpatch to v16, where the DEFAULT option was introduced. Author: Shinya Kato <shinya11.kato@gmail.com> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/CAOzEurT_PE7QEh5xAdb7Cja84Rur5qPv2Fzt3Tuqi=NU0WJsbg@mail.gmail.com Backpatch-through: 16	2 weeks ago
Michael Paquier	540c39cc56	doc: Improve description of pg_restore --jobs ... The parameter name used for the option value was named "number-of-jobs", which was inconsistent with what all the other tools with an option called --jobs use. This commit updates the parameter name to "njobs". Author: Tatsuro Yamada <yamatattsu@gmail.com> Discussion: https://postgr.es/m/CAOKkKFvHqA6Tny0RKkezWVfVV91nPJyj4OGtMi3C1RznDVXqrg@mail.gmail.com	3 weeks ago
Jacob Champion	e2aae8d68f	doc: Improve description of publish_via_partition_root ... Reword publish_via_partition_root's opening paragraph. Describe its behavior more clearly, and directly state that its default is false. Per complaint by Peter Smith; final text of the patch made in collaboration with Chao Li. Author: Chao Li <li.evan.chao@gmail.com> Author: Peter Smith <peter.b.smith@fujitsu.com> Reported-by: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: Amit Kapila <amit.kapila16@gmail.com> Discussion: https://postgr.es/m/CAHut%2BPu7SpK%2BctOYoqYR3V4w5LKc9sCs6c_qotk9uTQJQ4zp6g%40mail.gmail.com Backpatch-through: 14	3 weeks ago
Tom Lane	b352d3d80b	Mark GiST inet_ops as opcdefault, and deal with ensuing fallout. ... This patch completes the transition to making inet_ops be default for inet/cidr columns, rather than btree_gist's opclasses. Once we do that, though, pg_upgrade has a big problem. A dump from an older version will see btree_gist's opclasses as being default, so it will not mention the opclass explicitly in CREATE INDEX commands, which would cause the restore to create the indexes using inet_ops. Since that's not compatible with what's actually in the files, havoc would ensue. This isn't readily fixable, because the CREATE INDEX command strings are built by the older server's pg_get_indexdef() function; pg_dump hasn't nearly enough knowledge to modify those strings successfully. Even if we cared to put in the work to make that happen in pg_dump, it would be counterproductive because the end goal here is to get people off of these opclasses. Allowing such indexes to persist through pg_upgrade wouldn't advance that goal. Therefore, this patch just adds code to pg_upgrade to detect indexes that would be problematic and refuse to upgrade. There's another issue too: even without any indexes to worry about, pg_dump in binary-upgrade mode will reproduce the "CREATE OPERATOR CLASS ... DEFAULT" commands for btree_gist's opclasses, and those will fail because now we have a built-in opclass that provides a conflicting default. We could ask users to drop the btree_gist extension altogether before upgrading, but that would carry very severe penalties. It would affect perfectly-valid indexes for other data types, and it would drop operators that might be relied on in views or other database objects. Instead, put a hack in DefineOpClass to ignore the DEFAULT clauses for these opclasses when in binary-upgrade mode. This will result in installing a version of btree_gist that isn't quite the version it claims to be, but that can be fixed by issuing ALTER EXTENSION UPDATE afterwards. Since we don't apply that hack when not in binary-upgrade mode, it is now impossible to install any version of btree_gist less than 1.9 via CREATE EXTENSION. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Matthias van de Meent <boekewurm+postgres@gmail.com> Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Discussion: https://postgr.es/m/2483812.1754072263@sss.pgh.pa.us	3 weeks ago
Michael Paquier	639352d904	pg_createsubscriber: Improve handling of automated recovery configuration ... When repurposing a standby to a logical replica, pg_createsubscriber uses for the new replica a set of configuration parameters saved into postgresql.auto.conf, to force recovery patterns when the physical replica is promoted. While not wrong in practice, this approach can cause issues when forcing again recovery on a logical replica or its base backup as the recovery parameters are not reset on the target server once pg_createsubscriber is done with the node. This commit aims at improving the situation, by changing the way recovery parameters are saved on the target node. Instead of writing all the configuration to postgresql.auto.conf, this file now uses an include_if_exists, that points to a pg_createsubscriber.conf. This new file contains all the recovery configuration, and is renamed to pg_createsubscriber.conf.disabled when pg_createsubscriber exits. This approach resets the recovery parameters, and offers the benefit to keep a trace of the setup used when the target node got promoted, for debugging purposes. If pg_createsubscriber.conf cannot be renamed (unlikely scenario), a warning is issued to inform users that a manual intervention may be required to reset this configuration. This commit includes a test case to demonstrate the problematic case: a standby node created from a base backup of what was the target node of pg_createsubscriber does not get confused when started. If removing this new logic, the test fails with the standby not able to start due to an incorrect recovery target setup, where the startup process fails quickly with a FATAL. I have provided the design idea for the patch, that Alyona has written (with some code adjustments from me). This could be considered as a bug, but after discussion this is put into the bucket for improvements. Redesigning pg_createsubscriber would not be acceptable in the stable branches anyway. Author: Alyona Vinter <dlaaren8@gmail.com> Reviewed-by: Ilyasov Ian <ianilyasov@outlook.com> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Andrey Rudometov <unlimitedhikari@gmail.com> Discussion: https://postgr.es/m/CAGWv16K6L6Pzm99i1KiXLjFWx2bUS3DVsR6yV87-YR9QO7xb3A@mail.gmail.com	3 weeks ago
Nathan Bossart	a516b3f00d	MSVC: Support building for AArch64. ... This commit does the following to get tests passing for MSVC/AArch64: * Implements spin_delay() with an ISB instruction (like we do for gcc/clang on AArch64). * Sets USE_ARMV8_CRC32C unconditionally. Vendor-supported versions of Windows for AArch64 require at least ARMv8.1, which is where CRC extension support became mandatory. * Implements S_UNLOCK() with _InterlockedExchange(). The existing implementation for MSVC uses _ReadWriteBarrier() (a compiler barrier), which is insufficient for this purpose on non-TSO architectures. There are likely other changes required to take full advantage of the hardware (e.g., atomics/arch-arm.h, simd.h, pg_popcount_aarch64.c), but those can be dealt with later. Author: Niyas Sait <niyas.sait@linaro.org> Co-authored-by: Greg Burd <greg@burd.me> Co-authored-by: Dave Cramer <davecramer@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: John Naylor <johncnaylorls@gmail.com> Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Thomas Munro <thomas.munro@gmail.com> Tested-by: Andrew Dunstan <andrew@dunslane.net> Discussion: https://postgr.es/m/A6152C7C-F5E3-4958-8F8E-7692D259FF2F%40greg.burd.me Discussion: https://postgr.es/m/CAFPTBD-74%2BAEuN9n7caJ0YUnW5A0r-KBX8rYoEJWqFPgLKpzdg%40mail.gmail.com	3 weeks ago
Fujii Masao	1b795ef032	doc: Remove deprecated clauses from CREATE USER/GROUP syntax synopsis. ... The USER and IN GROUP clauses of CREATE ROLE are deprecated, and commit 8e78f0a1 removed them from the CREATE ROLE syntax syntax synopsis in the docs. However, previously CREATE USER and CREATE GROUP docs still listed these clauses. Since CREATE USER is equivalent to CREATE ROLE ... WITH LOGIN and CREATE GROUP is equivalent to CREATE ROLE, their documented syntax synopsis should match CREATE ROLE to avoid confusion. Therefore this commit removes the deprecated USER and IN GROUP clauses from the CREATE USER and CREATE GROUP syntax synopsis in the docs. Author: Japin Li <japinli@hotmail.com> Reviewed-by: wenhui qiu <qiuwenhuifx@gmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/MEAPR01MB3031C30E72EF16CFC08C8565B687A@MEAPR01MB3031.ausprd01.prod.outlook.com	3 weeks ago
John Naylor	ece25c2611	createuser: Update docs to reflect defaults ... Commit c7eab0e97 changed the default password_encryption setting to 'scram-sha-256', so update the example for creating a user with an assigned password. In addition, commit 08951a7c9 added new options that in turn pass default tokens NOBYPASSRLS and NOREPLICATION to the CREATE ROLE command, so fix this omission as well for v16 and later. Reported-by: Heikki Linnakangas <hlinnaka@iki.fi> Discussion: https://postgr.es/m/cff1ea60-c67d-4320-9e33-094637c2c4fb%40iki.fi Backpatch-through: 14	3 weeks ago
Michael Paquier	ba887a8cdb	Fix grammar in datatype.sgml ... Introduced in b139bd3b6e. Reported-by: Man Zeng <zengman@halodbtech.com> Discussion: https://postgr.es/m/tencent_121C1BB152CAF3195C99D56C@qq.com	3 weeks ago
John Naylor	e171405afe	Further doc updates to reflect MD5 deprecation ... Followup to 44f49511b. Author: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Discussion: https://postgr.es/m/CAHGQGwH_UfN96vcvLGA%3DYro%2Bo6qCn0nEgEGoviwzEiLTHtt2Pw%40mail.gmail.com Backpatch-through: 18	3 weeks ago
Fujii Masao	0a7c37b847	doc: Add glossary and index entries for GUC. ... GUC is a commonly used term but previously appeared only in the acronym documentation. This commit adds glossary and documentation index entries for GUC to make it easier to find and understand. Author: Robert Treat <rob@xzilla.net> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/CABV9wwPQnkeo_G6-orMGnHPK9SXGVWm7ajJPzsbE6944tDx=hQ@mail.gmail.com	3 weeks ago
Fujii Masao	466347ad28	doc: Add index entry for Git. ... This commit adds Git to the documentation index, pointing to the source code repository documentation. Author: Robert Treat <rob@xzilla.net> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/CABV9wwPQnkeo_G6-orMGnHPK9SXGVWm7ajJPzsbE6944tDx=hQ@mail.gmail.com	3 weeks ago
Michael Paquier	b139bd3b6e	Add data type oid8, 64-bit unsigned identifier ... This new identifier type provides support for 64-bit unsigned values, to be used in catalogs, like OIDs. An advantage of a new data type is that it becomes easier to grep for it in the code when assigning this type to a catalog attribute, linking it to dedicated APIs and internal structures. The following operators are added in this commit, with dedicated tests: - Casts with integer types and OID. - btree and hash operators - min/max functions. - C type with related macros and defines, named around "Oid8". This has been mentioned as useful on its own on the thread to add support for 64-bit TOAST values, so as it becomes possible to attach this data type to the TOAST code and catalog definitions. However, as this concept can apply to many more areas, it is implemented as its own independent change. This is based on a discussion with Andres Freund and Tom Lane. Bump catalog version. Author: Michael Paquier <michael@paquier.xyz> Reviewed-by: Greg Burd <greg@burd.me> Reviewed-by: Nikhil Kumar Veldanda <veldanda.nikhilkumar17@gmail.com> Discussion: https://postgr.es/m/1891064.1754681536@sss.pgh.pa.us	3 weeks ago
Michael Paquier	f1e251be80	Allow bgworkers to be terminated for database-related commands ... Background workers gain a new flag, called BGWORKER_INTERRUPTIBLE, that offers the possibility to terminate the workers when these are connected to a database that is involved in one of the following commands: ALTER DATABASE RENAME TO ALTER DATABASE SET TABLESPACE CREATE DATABASE DROP DATABASE This is useful to give background workers the same behavior as backends and autovacuum workers, which are stopped when these commands are executed. The default behavior, that exists since 9.3, is still to never terminate bgworkers connected to the database involved in any of these commands. The new flag has to be set to terminate the workers. A couple of tests are added to worker_spi to track the commands that impact the termination of the workers. There is a test case for a non-interruptible worker, additionally, that relies on an injection point to make the wait time in CountOtherDBBackends() reduced from 5s to 0.3s for faster test runs. The tests rely on the contents of the server logs to check if a worker has been started or terminated: - LOG generated by worker_spi_main() at startup, once connection to database is done. - FATAL in bgworker_die() when terminated. A couple of tests run in the CI have showed that this method is stable enough. The safe_psql() calls that scan pg_stat_activity could be replaced with some poll_query_until() for more stability, if the current method proves to be an issue in the buildfarm. Author: Aya Iwata <iwata.aya@fujitsu.com> Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Ryo Matsumura <matsumura.ryo@fujitsu.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Peter Smith <smithpb2250@gmail.com> Discussion: https://postgr.es/m/OS7PR01MB11964335F36BE41021B62EAE8EAE4A@OS7PR01MB11964.jpnprd01.prod.outlook.com	3 weeks ago
Fujii Masao	b9ee5f2dcb	doc: Fix outdated doc in pg_rewind. ... Update pg_rewind documentation to reflect the change that data checksums are now enabled by default during initdb. Backpatch to v18, where data checksums were changed to be enabled by default. Author: Zhijie Hou <houzj.fnst@fujitsu.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/TY4PR01MB16907D62F3A0A377B30FDBEA794B2A@TY4PR01MB16907.jpnprd01.prod.outlook.com Backpatch-through: 18	3 weeks ago
Tom Lane	7dc95cc3b9	Update to latest Snowball sources. ... It's been almost a year since we last did this, and upstream has been busy. They've added stemmers for Polish and Esperanto, and also deprecated their old Dutch stemmer in favor of the Kraaij-Pohlmann algorithm. (The "dutch" stemmer is now the latter, and "dutch_porter" is the old algorithm.) Upstream also decided to rename their internal header "header.h" to something less generic: "snowball_runtime.h". Seems like a good thing, but it complicates this patch a bit because we were relying on interposing our own version of "header.h" to control system header inclusion order. (We're partially failing at that now, because now the generated stemmer files include <stddef.h> before snowball_runtime.h. I think that'll be okay, but if the buildfarm complains then we'll have to do more-extensive editing of the generated files.) I realized that we weren't documenting the available stemmers in any user-visible place, except indirectly through sample \dFd output. That's incomplete because we only provide built-in dictionaries for the recommended stemmers for each language, not alternative stemmers such as dutch_porter. So I added a list to the documentation. I did not do anything with the stopword lists. If those are still available from snowballstem.org, they are mighty well hidden. Discussion: https://postgr.es/m/1185975.1767569534@sss.pgh.pa.us	4 weeks ago
Alexander Korotkov	49a181b5d6	Add the MODE option to the WAIT FOR LSN command ... This commit extends the WAIT FOR LSN command with an optional MODE option in the WITH clause that specifies which LSN type to wait for: WAIT FOR LSN '<lsn>' [WITH (MODE '<mode>', ...)] where mode can be: - 'standby_replay' (default): Wait for WAL to be replayed to the specified LSN, - 'standby_write': Wait for WAL to be written (received) to the specified LSN, - 'standby_flush': Wait for WAL to be flushed to disk at the specified LSN, - 'primary_flush': Wait for WAL to be flushed to disk on the primary server. The default mode is 'standby_replay', matching the original behavior when MODE is not specified. This follows the pattern used by COPY and EXPLAIN commands, where options are specified as string values in the WITH clause. Modes are explicitly named to distinguish between primary and standby operations: - Standby modes ('standby_replay', 'standby_write', 'standby_flush') can only be used during recovery (on a standby server), - Primary mode ('primary_flush') can only be used on a primary server. The 'standby_write' and 'standby_flush' modes are useful for scenarios where applications need to ensure WAL has been received or persisted on the standby without necessarily waiting for replay to complete. The 'primary_flush' mode allows waiting for WAL to be flushed on the primary server. This commit also includes includes: - Documentation updates for the new syntax and mode descriptions, - Test coverage for all four modes, including error cases and concurrent waiters, - Wakeup logic in walreceiver for standby write/flush waiters, - Wakeup logic in WAL writer for primary flush waiters. Discussion: https://postgr.es/m/CABPTF7UiArgW-sXj9CNwRzUhYOQrevLzkYcgBydmX5oDes1sjg%40mail.gmail.com Author: Xuneng Zhou <xunengzhou@gmail.com> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Alvaro Herrera <alvherre@kurilemu.de>	4 weeks ago
Michael Paquier	b8cfcb9e00	Fix typos and inconsistencies in code and comments ... This change is a cocktail of harmonization of function argument names, grammar typos, renames for better consistency and unused code (see ltree). All of these have been spotted by the author. Author: Alexander Lakhin <exclusion@gmail.com> Discussion: https://postgr.es/m/b2c0d0b7-3944-487d-a03d-d155851958ff@gmail.com	4 weeks ago
David Rowley	07e0e9ac27	Doc: add missing punctuation ... Author: Daisuke Higuchi <higuchi.daisuke11@gmail.com> Reviewed-by: Robert Treat <rob@xzilla.net> Discussion: https://postgr.es/m/CAEVT6c-yWYstu76YZ7VOxmij2XA8vrOEvens08QLmKHTDjEPBw@mail.gmail.com Backpatch-through: 14	4 weeks ago
Bruce Momjian	451c43974f	Update copyright for 2026 ... Backpatch-through: 14	4 weeks ago
Andrew Dunstan	f3c9e341cd	Add paths of extensions to pg_available_extensions ... Add a new "location" column to the pg_available_extensions and pg_available_extension_versions views, exposing the directory where the extension is located. The default system location is shown as '$system', the same value that can be used to configure the extension_control_path GUC. User-defined locations are only visible for super users, otherwise '<insufficient privilege>' is returned as a column value, the same behaviour that we already use in pg_stat_activity. I failed to resist the temptation to do a little extra editorializing of the TAP test script. Catalog version bumped. Author: Matheus Alcantara <mths.dev@pm.me> Reviewed-By: Chao Li <li.evan.chao@gmail.com> Reviewed-By: Rohit Prasad <rohit.prasad@arm.com> Reviewed-By: Michael Banck <mbanck@gmx.net> Reviewed-By: Manni Wood <manni.wood@enterprisedb.com> Reviewed-By: Euler Taveira <euler@eulerto.com> Reviewed-By: Quan Zongliang <quanzongliang@yeah.net>	4 weeks ago
Tom Lane	d6542f8dfc	Doc: remove obsolete, confused <note> about rowtype I/O syntax. ... This <note> was originally written to describe the double levels of de-backslashing encountered when a backslash-aware string literal is used to hold the text representation of a composite value. It still made sense when we switched to mostly using E'...' syntax for that type of literal. However, commit f77de4b0c mangled it completely by changing the example literal to be SQL-standard. The extra pass of de-backslashing described in the text doesn't actually occur with the example as written, unless you happen to be using standard_conforming_strings = off. We could restore this <note> to self-consistency by reverting the change from f77de4b0c, but on the whole I judge that its time has passed. standard_conforming_strings = off is nearly obsolete, and may soon be fully so. But without that, the behavior isn't so complicated as to justify a discursive note. I observe that the nearby section about array I/O syntax has no equivalent text, although that syntax is equally subject to this issue. Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/2998401.1767038920@sss.pgh.pa.us Discussion: https://postgr.es/m/3279216.1767072538@sss.pgh.pa.us	4 weeks ago
Tom Lane	bc6374cd76	Change IndexAmRoutines to be statically-allocated structs. ... Up to now, index amhandlers were expected to produce a new, palloc'd struct on each call. That requires palloc/pfree overhead, and creates a risk of memory leaks if the caller fails to pfree, and the time taken to fill such a large structure isn't nil. Moreover, we were storing these things in the relcache, eating several hundred bytes for each cached index. There is not anything in these structs that needs to vary at runtime, so let's change the definition so that an amhandler can return a pointer to a "static const" struct of which there's only one copy per index AM. Mark all the core code's IndexAmRoutine pointers const so that we catch anyplace that might still try to change or pfree one. (This is similar to the way we were already handling TableAmRoutine structs. This commit does fix one comment that was infelicitously copied-and-pasted into tableamapi.c.) This commit needs to be called out in the v19 release notes as an API change for extension index AMs. An un-updated AM will still work (as of now, anyway) but it risks memory leaks and will be slower than necessary. Author: Matthias van de Meent <boekewurm+postgres@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/CAEoWx2=vApYk2LRu8R0DdahsPNEhWUxGBZ=rbZo1EXE=uA+opQ@mail.gmail.com	1 month ago
Michael Paquier	97b101776c	Add pg_get_multixact_stats() ... This new function exposes at SQL level some information related to multixacts, not available until now. This data is useful for monitoring purposes, especially for workloads that make a heavy use of multixacts: - num_mxids, number of MultiXact IDs in use. - num_members, number of member entries in use. - members_size, bytes used by num_members in pg_multixact/members/. - oldest_multixact: oldest MultiXact still needed. This patch has been originally proposed when MultiXactOffset was still 32 bits, to monitor wraparound. This part is not relevant anymore since bd8d9c9bdf that has widen MultiXactOffset to 64 bits. The monitoring of disk space usage for the members is still relevant. Some tests are added to check this function, in the shape of one isolation test with concurrent transactions that take a ROW SHARE lock, and some SQL tests for pg_read_all_stats. Some documentation is added to explain some patterns that can come from the information provided by the function. Bump catalog version. Author: Naga Appani <nagnrik@gmail.com> Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Atsushi Torikoshi <torikoshia@oss.nttdata.com> Discussion: https://postgr.es/m/CA+QeY+AAsYK6WvBW4qYzHz4bahHycDAY_q5ECmHkEV_eB9ckzg@mail.gmail.com	1 month ago
Daniel Gustafsson	a9123db14a	Fix incorrectly spelled city name ... The correct spelling is Beijing, fix in regression test and docs. Author: JiaoShuntian <jiaoshuntian@gmail.com> Reviewed-by: Kirill Reshke <reshkekirill@gmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Discussion: https://postgr.es/m/ebfa3ec2-dc3c-4adb-be2a-4a882c2e85a7@gmail.com	1 month ago
Bruce Momjian	e82e9aaa6a	doc: warn about the use of "ctid" queries beyond the examples ... Also be more assertive that "ctid" should not be used for long-term storage. Reported-by: Bernice Southey Discussion: https://postgr.es/m/CAEDh4nyn5swFYuSfcnGAbpQrKOc47Hh_ZyKVSPYJcu2P=51Luw@mail.gmail.com Backpatch-through: 17	1 month ago
Michael Paquier	f8a4cad8f4	doc: Remove duplicate word in ECPG description ... Author: Laurenz Albe <laurenz.albe@cybertec.at> Reviewed-by: vignesh C <vignesh21@gmail.com> Discussion: https://postgr.es/m/d6d6a800f8b503cd78d5f4fa721198e40eec1677.camel@cybertec.at Backpatch-through: 14	1 month ago
Bruce Momjian	41808377fe	doc: change "can not" to "cannot" ... Reported-by: Chao Li Author: Chao Li Discussion: https://postgr.es/m/CAEoWx2kyiD+7-vUoOYhH=y2Hrmvqyyhm4EhzgKyrxGBXOMWCxw@mail.gmail.com	1 month ago
Fujii Masao	008beba005	doc: Use proper tags in pg_overexplain documentation. ... The pg_overexplain documentation previously used the <literal> tag for some file names, struct names, and commands. Update the markup to use the more appropriate tags: <filename>, <structname>, and <command>. Backpatch to v18, where pg_overexplain was introduced. Author: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Shixin Wang <wang-shi-xin@outlook.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Discussion: https://postgr.es/m/CAHGQGwEyYUzz0LjBV_fMcdwU3wgmu0NCoT+JJiozPa8DG6eeog@mail.gmail.com Backpatch-through: 18	1 month ago
Amit Kapila	dc6c879455	Doc: Clarify publication privilege requirements. ... Update the logical replication documentation to explicitly outline the privilege requirements for each publication syntax. This will ensure users understand the necessary permissions when creating or managing publications. Author: Shlok Kyal <shlok.kyal.oss@gmail.com> Reviewed-by: Peter Smith <smithpb2250@gmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Reviewed-by: David G. Johnston <david.g.johnston@gmail.com> Discussion: https://postgr.es/m/CANhcyEXODen4U0XLk0aAwFTwGxjAfE9eRaynREenLp-JBSaFHw@mail.gmail.com	1 month ago
Masahiko Sawada	67c20979ce	Toggle logical decoding dynamically based on logical slot presence. ... Previously logical decoding required wal_level to be set to 'logical' at server start. This meant that users had to incur the overhead of logical-level WAL logging even when no logical replication slots were in use. This commit adds functionality to automatically control logical decoding availability based on logical replication slot presence. The newly introduced module logicalctl.c allows logical decoding to be dynamically activated when needed when wal_level is set to 'replica'. When the first logical replication slot is created, the system automatically increases the effective WAL level to maintain logical-level WAL records. Conversely, after the last logical slot is dropped or invalidated, it decreases back to 'replica' WAL level. While activation occurs synchronously right after creating the first logical slot, deactivation happens asynchronously through the checkpointer process. This design avoids a race condition at the end of recovery; a concurrent deactivation could happen while the startup process enables logical decoding at the end of recovery, but WAL writes are still not permitted until recovery fully completes. The checkpointer will handle it after recovery is done. Asynchronous deactivation also avoids excessive toggling of the logical decoding status in workloads that repeatedly create and drop a single logical slot. On the other hand, this lazy approach can delay changes to effective_wal_level and the disabling logical decoding, especially when the checkpointer is busy with other tasks. We chose this lazy approach in all deactivation paths to keep the implementation simple, even though laziness is strictly required only for end-of-recovery cases. Future work might address this limitation either by using a dedicated worker instead of the checkpointer, or by implementing synchronous waiting during slot drops if workloads are significantly affected by the lazy deactivation of logical decoding. The effective WAL level, determined internally by XLogLogicalInfo, is allowed to change within a transaction until an XID is assigned. Once an XID is assigned, the value becomes fixed for the remainder of the transaction. This behavior ensures that the logging mode remains consistent within a writing transaction, similar to the behavior of GUC parameters. A new read-only GUC parameter effective_wal_level is introduced to monitor the actual WAL level in effect. This parameter reflects the current operational WAL level, which may differ from the configured wal_level setting. Bump PG_CONTROL_VERSION as it adds a new field to CheckPoint struct. Reviewed-by: Shveta Malik <shveta.malik@gmail.com> Reviewed-by: Amit Kapila <amit.kapila16@gmail.com> Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com> Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com> Reviewed-by: Peter Smith <smithpb2250@gmail.com> Reviewed-by: Shlok Kyal <shlok.kyal.oss@gmail.com> Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> Discussion: https://postgr.es/m/CAD21AoCVLeLYq09pQPaWs+Jwdni5FuJ8v2jgq-u9_uFbcp6UbA@mail.gmail.com	1 month ago
Bruce Momjian	ea97154fc2	doc: add "DO" to "ON CONFLICT" in CREATE VIEW text ... This is done for consistency. Reported-by: jian he Author: Laurenz Albe Discussion: https://postgr.es/m/CACJufxEW1RRDD9ZWGcW_Np_Z9VGPE-YC7u0C6RcsEY8EKiTdBg@mail.gmail.com	1 month ago
Fujii Masao	c5d162435a	doc: Fix incorrect reference in pg_overexplain documentation. ... Correct the referenced location of the RangeTblEntry definition in the pg_overexplain documentation. Backpatched to v18, where pg_overexplain was introduced. Author: Julien Tachoires <julien@tachoires.me> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/20251218092319.tht64ffmcvzqdz7u@poseidon.home.virt Backpatch-through: 18	1 month ago
Bruce Momjian	80f08a6e6a	doc: clarify when physical/logical replication is used ... The imprecision caused some text to be only partially accurate. Reported-by: Paul A Jungwirth Author: Robert Treat Discussion: https://postgr.es/m/CA%2BrenyULt3VBS1cRFKUfT2%3D5dr61xBOZdAZ-CqX3XLGXqY-aTQ%40mail.gmail.com	1 month ago