pgsql: pgbench: Fix error reporting in readCommandResponse().
pgbench: Fix error reporting in readCommandResponse(). pgbench uses readCommandResponse() to process server responses. When readCommandResponse() encounters an error during a call to PQgetResult() to fetch the current result, it attempts to report it with an additional error message from PQerrorMessage(). However, previously, this extra error message could be lost or become incorrect. The cause was that after fetching the current result (and detecting an error), readCommandResponse() called PQgetResult() again to peek at the next result. This second call could overwrite the libpq connection's error message before the original error was reported, causing the error message retrieved from PQerrorMessage() to be lost or overwritten. This commit fixes the issue by updating readCommandResponse() to use PQresultErrorMessage() instead of PQerrorMessage() to retrieve the error message generated when the PQgetResult() for the current result causes an error, ensuring the correct message is reported. Backpatch to all supported versions. Author: Yugo Nagata Reviewed-by: Chao Li Reviewed-by: Fujii Masao Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/36c4d30c8f2474cb9bc5f4eb0f2bec4c5a314003 Modified Files -- src/bin/pgbench/pgbench.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: pgbench: Fix error reporting in readCommandResponse().
pgbench: Fix error reporting in readCommandResponse(). pgbench uses readCommandResponse() to process server responses. When readCommandResponse() encounters an error during a call to PQgetResult() to fetch the current result, it attempts to report it with an additional error message from PQerrorMessage(). However, previously, this extra error message could be lost or become incorrect. The cause was that after fetching the current result (and detecting an error), readCommandResponse() called PQgetResult() again to peek at the next result. This second call could overwrite the libpq connection's error message before the original error was reported, causing the error message retrieved from PQerrorMessage() to be lost or overwritten. This commit fixes the issue by updating readCommandResponse() to use PQresultErrorMessage() instead of PQerrorMessage() to retrieve the error message generated when the PQgetResult() for the current result causes an error, ensuring the correct message is reported. Backpatch to all supported versions. Author: Yugo Nagata Reviewed-by: Chao Li Reviewed-by: Fujii Masao Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/cb21e1f92fb3b9c2208611db8c7051660fc0afb2 Modified Files -- src/bin/pgbench/pgbench.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: doc: Remove trailing whitespace in xref
doc: Remove trailing whitespace in xref Remove stray whitespace in xref tag. This was found due to a regression in xmllint 2.15.0 which flagged this as an error, and at the time of this commit no fix for xmllint has shipped. Author: Erik Wienhold Discussion: https://postgr.es/m/[email protected] Backpatch-through: 17 Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/987e00fa990fc905fe8fab645a16f7a4be3d9126 Modified Files -- doc/src/sgml/ref/pg_combinebackup.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Change config_generic.vartype to be initialized at compile time
Change config_generic.vartype to be initialized at compile time Previously, this was initialized at run time so that it did not have to be maintained by hand in guc_tables.c. But since that table is now generated anyway, we might as well generate this bit as well. Reviewed-by: Chao Li Discussion: https://www.postgresql.org/message-id/flat/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e1a912c86d5205371b043772aa89908f2452cbf0 Modified Files -- src/backend/utils/misc/gen_guc_tables.pl | 1 + src/backend/utils/misc/guc.c | 28 +--- src/include/utils/guc_tables.h | 2 +- 3 files changed, 3 insertions(+), 28 deletions(-)
Re: pgsql: Fix meson build with -Duuid=ossp when using version older than 0
Michael Paquier writes: > Argh. Sorry about that! Would you prefer if I revert immediately on > ~18? Yeah, reverting on 18 and leaving the other branches alone would be fine with me. We can put it back in 18 after the release. regards, tom lane
pgsql: Restore test coverage of LZ4Stream_gets().
Restore test coverage of LZ4Stream_gets(). In commit a45c78e32 I removed the only regression test case that reaches this function, because it turns out that we only use it if reading an LZ4-compressed blobs.toc file in a directory dump, and that is a state that has to be created manually. That seems like a bad thing to not test, not so much for LZ4Stream_gets() itself as because it means the squirrely eol_flag logic in LZ4Stream_read_internal() is not tested. The reason for the change was that I thought the lz4 program did not have any way to perform compression without explicit specification of the output file name. However, it turns out that the syntax synopsis in its man page is a lie, and if you read enough of the man page you find out that with "-m" it will do what's needful. So restore the manual compression step in that test case. Noted while testing some proposed changes in pg_dump's compression logic. Author: Tom Lane Discussion: https://postgr.es/m/[email protected] Backpatch-through: 17 Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/eac2b1697d48b2ee5e6836fb63ae0966363055c2 Modified Files -- src/bin/pg_dump/t/002_pg_dump.pl | 9 + 1 file changed, 9 insertions(+)
pgsql: Fix two typos in xlogstats.h and xlogstats.c
Fix two typos in xlogstats.h and xlogstats.c Issue found while browsing this area of the code, introduced and copy-pasted around by 2258e76f90bf. Backpatch-through: 15 Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ed047ce0a881e628a17e0a3fe6a19c0faa155563 Modified Files -- src/backend/access/transam/xlogstats.c | 2 +- src/include/access/xlogstats.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
pgsql: doc: Add missing parenthesis in pg_stat_progress_analyze docs
doc: Add missing parenthesis in pg_stat_progress_analyze docs Author: Shinya Kato Discussion: https://postgr.es/m/caozeurrgpah9dsbem88fpohnav_pkdl6p_9mjatcrnf9wxw...@mail.gmail.com Backpatch-through: 18 Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9ea4a2b4f1cccba37935522920a933c67421476b Modified Files -- doc/src/sgml/monitoring.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: pgbench: Fix error reporting in readCommandResponse().
pgbench: Fix error reporting in readCommandResponse(). pgbench uses readCommandResponse() to process server responses. When readCommandResponse() encounters an error during a call to PQgetResult() to fetch the current result, it attempts to report it with an additional error message from PQerrorMessage(). However, previously, this extra error message could be lost or become incorrect. The cause was that after fetching the current result (and detecting an error), readCommandResponse() called PQgetResult() again to peek at the next result. This second call could overwrite the libpq connection's error message before the original error was reported, causing the error message retrieved from PQerrorMessage() to be lost or overwritten. This commit fixes the issue by updating readCommandResponse() to use PQresultErrorMessage() instead of PQerrorMessage() to retrieve the error message generated when the PQgetResult() for the current result causes an error, ensuring the correct message is reported. Backpatch to all supported versions. Author: Yugo Nagata Reviewed-by: Chao Li Reviewed-by: Fujii Masao Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13 Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a912118c6055f683d51763546ee3c14b6e732893 Modified Files -- src/bin/pgbench/pgbench.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: Add comment in ginxlog.h about block used with ginxlogInsertList
Add comment in ginxlog.h about block used with ginxlogInsertListPage All the other structures describe the list of blocks used, and in the case of a GIN_INSERT_LISTPAGE record block 0 refers to a list page with the items added to it. Author: Kirill Reshke Reviewed-by: Andrey Borodin Discussion: https://postgr.es/m/CALdSSPgk=9WRoXhZy5fdk+T1hiau7qbL_vn94w_L1N=gted...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/42c6b74d8928885135ba35ffdb7fb60602953e2d Modified Files -- src/include/access/ginxlog.h | 3 +++ 1 file changed, 3 insertions(+)
pgsql: Fix lookups in pg_{clear,restore}_{attribute,relation}_stats().
Fix lookups in pg_{clear,restore}_{attribute,relation}_stats().
Presently, these functions look up the relation's OID, lock it, and
then check privileges. Not only does this approach provide no
guarantee that the locked relation matches the arguments of the
lookup, but it also allows users to briefly lock relations for
which they do not have privileges, which might enable
denial-of-service attacks. This commit adjusts these functions to
use RangeVarGetRelidExtended(), which is purpose-built to avoid
both of these issues. The new RangeVarGetRelidCallback function is
somewhat complicated because it must handle both tables and
indexes, and for indexes, we must check privileges on the parent
table and lock it first. Also, it needs to handle a couple of
extremely unlikely race conditions involving concurrent OID reuse.
A downside of this change is that the coding doesn't allow for
locking indexes in AccessShare mode anymore; everything is locked
in ShareUpdateExclusive mode. Per discussion, the original choice
of lock levels was intended for a now defunct implementation that
used in-place updates, so we believe this change is okay.
Reviewed-by: Jeff Davis
Discussion: https://postgr.es/m/Z8zwVmGzXyDdkAXj%40nathan
Backpatch-through: 18
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/688dc6299a5bda3221db99fdd957ac9edf11c8a6
Modified Files
--
src/backend/statistics/attribute_stats.c | 16 +--
src/backend/statistics/relation_stats.c| 8 +-
src/backend/statistics/stat_utils.c| 152 +++--
src/include/statistics/stat_utils.h| 8 +-
src/test/regress/expected/stats_import.out | 6 +-
5 files changed, 103 insertions(+), 87 deletions(-)
pgsql: Doc: clarify n_distinct_inherited setting
Doc: clarify n_distinct_inherited setting There was some confusion around how to adjust the n_distinct estimates for partitioned tables. Here we try and clarify that n_distinct_inherited needs to be adjusted rather than n_distinct. Also fix some slightly misleading text which was talking about table size rather than table rows, fix a grammatical error, and adjust some text which indicated that ANALYZE was performing calculations based on the n_distinct settings. Really it's the query planner that does this and ANALYZE only stores the overridden n_distinct estimate value in pg_statistic. Author: David Rowley Reviewed-by: David G. Johnston Reviewed-by: Chao Li Backpatch-through: 13 Discussion: https://postgr.es/m/CAApHDvrL7a-ZytM1SP8Uk9nEw9bR2CPzVb+uP+bcNj=_q-z...@mail.gmail.com Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/715eb62e30ac54963be63f625a1d8d50fa7d29b7 Modified Files -- doc/src/sgml/ref/alter_table.sgml | 34 -- 1 file changed, 16 insertions(+), 18 deletions(-)
pgsql: Doc: clarify n_distinct_inherited setting
Doc: clarify n_distinct_inherited setting There was some confusion around how to adjust the n_distinct estimates for partitioned tables. Here we try and clarify that n_distinct_inherited needs to be adjusted rather than n_distinct. Also fix some slightly misleading text which was talking about table size rather than table rows, fix a grammatical error, and adjust some text which indicated that ANALYZE was performing calculations based on the n_distinct settings. Really it's the query planner that does this and ANALYZE only stores the overridden n_distinct estimate value in pg_statistic. Author: David Rowley Reviewed-by: David G. Johnston Reviewed-by: Chao Li Backpatch-through: 13 Discussion: https://postgr.es/m/CAApHDvrL7a-ZytM1SP8Uk9nEw9bR2CPzVb+uP+bcNj=_q-z...@mail.gmail.com Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f691e72585a3811a05e37d27e898b1d816ff9ff9 Modified Files -- doc/src/sgml/ref/alter_table.sgml | 34 -- 1 file changed, 16 insertions(+), 18 deletions(-)
pgsql: Remove state.tmp when failing to save a replication slot
Remove state.tmp when failing to save a replication slot An error happening while a slot data is saved on disk in SaveSlotToPath() could cause a state.tmp file (temporary file holding the slot state data, renamed to its permanent name at the end of the function) to remain around after it has been created. This temporary file is created with O_EXCL, meaning that if an existing state.tmp is found, its creation would fail. This would prevent the slot data to be saved, requiring a manual intervention to remove state.tmp before being able to save again a slot. Possible scenarios where this temporary file could remain on disk is for example a ENOSPC case (no disk space) while writing, syncing or renaming it. The bug reports point to a write failure as the principal cause of the problems. Using O_TRUNC has been argued back in 2019 as a potential solution to discard any temporary file that could exist. This solution was rejected as O_EXCL can also act as a safety measure when saving the slot state, crash recovery offering cleanup guarantees post-crash. This commit uses the alternative approach that has been suggested by Andres Freund back in 2019. When the temporary state file cannot be written, synced, closed or renamed (note: not when created!), an unlink() is used to remove the temporary state file while holding the in-progress I/O LWLock, so as any follow-up attempts to save a slot's data would not choke on an existing file that remained around because of a previous failure. This problem has been reported a few times across the years, going back to 2019, but for some reason I have never come back to do something about it and it has been forgotten. A recent report has reminded me that this was still a problem. Reported-by: Kevin K Biju Reported-by: Sergei Kornilov Reported-by: Grigory Smolkin Discussion: https://postgr.es/m/cam45keha32sokl_g8vk38cwvtbeooxcsxapas7jt7yprf2m...@mail.gmail.com Discussion: https://postgr.es/m/[email protected] Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/bfdd1a12d2d90a255d3e5cc582e2cb3f4a347e53 Modified Files -- src/backend/replication/slot.c | 7 +++ 1 file changed, 7 insertions(+)
pgsql: Revert "Make some use of anonymous unions [pgcrypto]"
Revert "Make some use of anonymous unions [pgcrypto]" This reverts commit efcd5199d8cb8e5098f79b38d0c46004e69d1a46. I rebased my patch series incorrectly. This patch contained unrelated parts from another patch, which made the overall build fail. Revert for now and reconsider. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f5aabe6d58e08179cc656539c4bd0145525bf22f Modified Files -- contrib/pgcrypto/openssl.c | 14 +++--- contrib/pgcrypto/px.h | 2 +- src/common/cryptohash.c| 36 ++-- 3 files changed, 26 insertions(+), 26 deletions(-)
pgsql: Modernize some for loops
Modernize some for loops in guc-related source files, in anticipation of some further restructuring. Reviewed-by: Chao Li Discussion: https://www.postgresql.org/message-id/flat/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/1a79519cc630f4f9ce617bfc28fb2aa1432f Modified Files -- src/backend/utils/misc/guc.c | 135 +-- src/backend/utils/misc/guc_funcs.c | 3 +- src/backend/utils/misc/help_config.c | 5 +- 3 files changed, 53 insertions(+), 90 deletions(-)
pgsql: doc: Remove trailing whitespace in xref
doc: Remove trailing whitespace in xref Remove stray whitespace in xref tag. This was found due to a regression in xmllint 2.15.0 which flagged this as an error, and at the time of this commit no fix for xmllint has shipped. Author: Erik Wienhold Discussion: https://postgr.es/m/[email protected] Backpatch-through: 17 Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0072fb3076cdd45cdd1c2b0f2335b9c7dea511ad Modified Files -- doc/src/sgml/ref/pg_combinebackup.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Fix incorrect targetlist in dummy UNIONs
Fix incorrect targetlist in dummy UNIONs The prior code, added in 03d40e4b5 attempted to use the targetlist of the first UNION child when all UNION children were proven as dummy rels. That's not going to work when some operation atop of the Result node must find target entries within the Result's targetlist. This could have been something as simple as trying to sort the results of the UNION operation, which would lead to: ERROR: could not find pathkey item to sort Instead, use the top-level UNION's targetlist and fix the varnos in setrefs.c. Because set operation targetlists always use varno==0, we can rewrite those to become varno==1, i.e. use the Vars from the first UNION child. This does result in showing Vars from relations that are not present in the final plan, but that's no different to what we see when normal base relations are proven dummy. Without this fix it would be possible to see the following error in EXPLAIN VERBOSE when all UNION inputs were proven empty. ERROR: bogus varno: 0 Author: David Rowley Discussion: https://postgr.es/m/caaphdvruasy9sfulmesm2udvzjp6aobrczvhyxyxzty2tx9...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/928df067d1e6ca5b747722d32c79bc3efa891a32 Modified Files -- src/backend/optimizer/plan/setrefs.c | 27 +++ src/backend/optimizer/prep/prepunion.c | 1 - src/test/regress/expected/union.out| 18 +++--- src/test/regress/sql/union.sql | 3 ++- 4 files changed, 36 insertions(+), 13 deletions(-)
pgsql: Use bms_add_members() instead of bms_union() when possible
Use bms_add_members() instead of bms_union() when possible bms_union() causes a new set to be allocated. What this caller needs is members added to an existing set. bms_add_members() is the tool for that job. This is just a matter of fixing an inefficiency due to surplus memory allocations. No bugs being fixed. The only other place I found that might be valid to apply this change is in markNullableIfNeeded(), but I opted not to do that due to the risk to reward ratio not looking favorable. The risk being that there *could* be another pointer pointing to the Bitmapset. Author: David Rowley Reviewed-by: Greg Burd Reviewed-by: Tom Lane Discussion: https://postgr.es/m/caaphdvoccos-p5tznjltxfoktynjqvh7dwf+5ikdubwnvwf...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/5092aae431e3e1a20324ea3a42a181c63f703d0d Modified Files -- src/backend/optimizer/prep/prepunion.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Inline TransactionIdFollows/Precedes[OrEquals]()
Inline TransactionIdFollows/Precedes[OrEquals]() These functions appeared prominently in a profile of a patch that sets the visibility map on-access. Inline them to remove call overhead and make them cheaper to use in hot paths. Author: Melanie Plageman Reviewed-by: Kirill Reshke Reviewed-by: Andres Freund Discussion: https://postgr.es/m/2wk7jo4m4qwh5sn33pfgerdjfujebbccsmmlownybddbh6nawl%40mdyyqpqzxjek Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/43b05b38ea4d03a0ee9a09f08a9559bc0ca6d7ad Modified Files -- src/backend/access/transam/transam.c | 64 - src/include/access/transam.h | 70 +--- 2 files changed, 66 insertions(+), 68 deletions(-)
pgsql: Stamp 18.0.
Stamp 18.0. Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/3d6a828938a5fa0444275d3d2f67b64ec3199eb7 Modified Files -- configure| 18 +- configure.ac | 2 +- meson.build | 2 +- 3 files changed, 11 insertions(+), 11 deletions(-)
pgsql: Remove unnecessary include of "utils/fmgroids.h"
Remove unnecessary include of "utils/fmgroids.h" In initsplan.c, no macros for built-in function OIDs are used, so this include is unnecessary and can be removed. This was my oversight in commit 8e1185910. Discussion: https://postgr.es/m/CAMbWs4_-sag-cAKrLJ+X+5njL1=oudk=+KfLmsLZ5a2jckn=k...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f997d777adf725c674e1bfcff086487f2427759e Modified Files -- src/backend/optimizer/plan/initsplan.c | 1 - 1 file changed, 1 deletion(-)
pgsql: Remove unused nbtree array advancement variable.
Remove unused nbtree array advancement variable. Remove a variable that is no longer in use following commit 9a2e2a28. It's not immediately clear why there were no compiler warnings about this oversight. Author: Peter Geoghegan Backpatch-through: 18 Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9de72704e060720c58f75a715e3f217ad8635276 Modified Files -- src/backend/access/nbtree/nbtutils.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
pgsql: Add mem_exceeded_count column to pg_stat_replication_slots.
Add mem_exceeded_count column to pg_stat_replication_slots. This commit introduces a new column mem_exceeded_count to the pg_stat_replication_slots view. This counter tracks how often the memory used by logical decoding exceeds the logical_decoding_work_mem limit. The new statistic helps users determine whether exceeding the logical_decoding_work_mem limit is a rare occurrences or a frequent issue, information that wasn't available through existing statistics. Bumps catversion. Author: Bertrand Drouvot Reviewed-by: Masahiko Sawada Reviewed-by: Amit Kapila Reviewed-by: shveta malik Reviewed-by: Ashutosh Bapat Reviewed-by: Chao Li Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d3b6183dd988928dd369b4b7d641917e77f1ae4e Modified Files -- contrib/test_decoding/expected/stats.out| 71 + contrib/test_decoding/sql/stats.sql | 13 +++-- doc/src/sgml/monitoring.sgml| 11 src/backend/catalog/system_views.sql| 1 + src/backend/replication/logical/logical.c | 8 ++- src/backend/replication/logical/reorderbuffer.c | 34 +--- src/backend/utils/activity/pgstat_replslot.c| 1 + src/backend/utils/adt/pgstatfuncs.c | 19 --- src/include/catalog/catversion.h| 2 +- src/include/catalog/pg_proc.dat | 6 +-- src/include/pgstat.h| 1 + src/include/replication/reorderbuffer.h | 3 ++ src/test/regress/expected/rules.out | 3 +- 13 files changed, 113 insertions(+), 60 deletions(-)
pgsql: Correct prune WAL record opcode name in comment
Correct prune WAL record opcode name in comment f83d709760d8 incorrectly refers to a XLOG_HEAP2_PRUNE_FREEZE WAL record opcode. No such code exists. The relevant opcodes are XLOG_HEAP2_PRUNE_ON_ACCESS, XLOG_HEAP2_PRUNE_VACUUM_SCAN, and XLOG_HEAP2_PRUNE_VACUUM_CLEANUP. Correct it. Author: Melanie Plageman Reviewed-by: Andres Freund Discussion: https://postgr.es/m/yn4zp35kkdsjx6wf47zcfmxgexxt4h2og47pvnw2x5ifyrs3qc%407uw6jyyxuyf7 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ae8ea7278c16a23aa7dfb56c531706c18628ba55 Modified Files -- src/backend/access/heap/pruneheap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Add support for tracking of entry count in pgstats
Add support for tracking of entry count in pgstats Stats kinds can set a new option called "track_entry_count" (disabled by default, available for variable-numbered stats) that will make pgstats track the number of entries that exist in its shared hashtable. As there is only one code path where a new entry is added, and one code path where entries are freed, the count tracking is straight-forward in its implementation. Reads of these counters are optimistic, and may change across two calls. The counter is incremented when an entry is created (not when reused), and is decremented when an entry is freed from the hashtable (marked for drop with its refcount reaching 0), which is something that pgstats decides internally. A first use case of this facility would be pg_stat_statements, where we need to be able to cap the number of entries that would be stored in the shared hashtable, based on its "max" GUC. The module currently relies on hash_get_num_entries(), which offers a cheap way to count how many entries are in its hash table, but we cannot do that in pgstats for variable-sized stats kinds as a single hashtable is used for all the stats kinds. Independently of PGSS, this is useful for other custom stats kinds that want to cap, control, or track the number of entries they have, without depending on a potentially expensive sequential scan to know the number of entries while holding an extra exclusive lock. Author: Michael Paquier Reviewed-by: Sami Imseih Reviewed-by: Keisuke Kuroda Reviewed-by: Chao Li Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7bd2975fa92bd6b5ade5e34f75d474ac838ec0c6 Modified Files -- src/backend/utils/activity/pgstat.c | 4 +++ src/backend/utils/activity/pgstat_shmem.c | 44 ++- src/include/utils/pgstat_internal.h | 27 +++ 3 files changed, 62 insertions(+), 13 deletions(-)
pgsql: Use designated initializers for guc_tables
Use designated initializers for guc_tables This makes the generating script simpler and the output easier to read. In the future, it will make it easier to reorder and rearrange the underlying C structures. Reviewed-by: Chao Li Discussion: https://www.postgresql.org/message-id/flat/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0a7bde46101697ece7549df29078ff9417347438 Modified Files -- src/backend/utils/misc/gen_guc_tables.pl | 53 +--- 1 file changed, 22 insertions(+), 31 deletions(-)
pgsql: Fix matching check in recovery test 042_low_level_backup
Fix matching check in recovery test 042_low_level_backup 042_low_level_backup compared the result of a query two times with a comparison operator based on an integer, while the result should be compared with a string. The outcome of the tests is currently not impacted by this change. However, it could be possible that the tests fail to detect future issues if the query results become different, for some reason. Oversight in 99b4a63bef94. Author: Sadhuprasad Patro Discussion: https://postgr.es/m/caff0-chhwnx_cv2uy7tkjodubeogprjpw4rpf1jqb16_1bu...@mail.gmail.com Backpatch-through: 17 Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/3a7225ed37fc0819f689e17435dc590fd2b8980d Modified Files -- src/test/recovery/t/042_low_level_backup.pl | 8 1 file changed, 4 insertions(+), 4 deletions(-)
pgsql: pg_regc_locale.c: rename some static functions.
pg_regc_locale.c: rename some static functions. Use the more specific prefix "regc_" rather than the generic prefix "pg_". A subsequent commit will create generic versions of some of these functions that can be called from other modules. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8efe982fe2c5b900554d489c0409618638193aef Modified Files -- src/backend/regex/regc_locale.c| 54 +++--- src/backend/regex/regc_pg_locale.c | 34 src/backend/regex/regcomp.c| 24 - src/include/regex/regcustom.h | 8 +++--- 4 files changed, 60 insertions(+), 60 deletions(-)
pgsql: Fix EPQ crash from missing partition directory in EState
Fix EPQ crash from missing partition directory in EState EvalPlanQualStart() failed to propagate es_partition_directory into the child EState used for EPQ rechecks. When execution time partition pruning ran during the EPQ scan, executor code dereferenced a NULL partition directory and crashed. Previously, propagating es_partition_directory into the EPQ EState was unnecessary because CreatePartitionPruneState(), which sets it on demand, also initialized the exec-pruning context. After commit d47cbf474, CreatePartitionPruneState() now initializes only the init- time pruning context, leaving exec-pruning context initialization to ExecInitNode(). Since EvalPlanQualStart() runs only ExecInitNode() and not CreatePartitionPruneState(), it can encounter a NULL es_partition_directory. Other executor fields initialized during CreatePartitionPruneState() are already copied into the child EState thanks to commit 8741e48e5d, but es_partition_directory was missed. Fix by borrowing the parent estate's es_partition_directory in EvalPlanQualStart(), and by clearing that field in EvalPlanQualEnd() so the parent remains responsible for freeing the directory. Add an isolation test permutation that triggers EPQ with execution- time partition pruning, the case that reproduces this crash. Bug: #19078 Reported-by: Yuri Zamyatin Diagnosed-by: David Rowley Author: David Rowley Co-authored-by: Amit Langote Discussion: https://postgr.es/m/[email protected] Backpatch-through: 18 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/905e932f0922a837bb3e4e482089c7c2e98bea67 Modified Files -- src/backend/executor/execMain.c| 10 ++ src/test/isolation/expected/eval-plan-qual.out | 7 +++ src/test/isolation/specs/eval-plan-qual.spec | 2 ++ 3 files changed, 19 insertions(+)
Re: pgsql: Move gramparse.h to src/backend/parser
Hi! On 15.09.2022 06:52, John Naylor wrote: On Thu, Sep 15, 2022 at 4:04 AM Andres Freund wrote: The most general solution I can see would be diff --git i/src/backend/common.mk w/src/backend/common.mk index fa96a82b1a0..61861f5c7eb 100644 --- i/src/backend/common.mk +++ w/src/backend/common.mk @@ -23,6 +23,7 @@ objfiles.txt: Makefile $(SUBDIROBJS) $(OBJS) ifeq ($(with_llvm), yes) objfiles.txt: $(patsubst %.o,%.bc, $(OBJS)) +$(patsubst %.o,%.bc, $(OBJS)): $(OBJS) endif Since there have been no other ideas in the past few hours, I will push this but it will be a blind attempt since it seems sporadic and doesn't happen to reproduce for me. My colleague Marina Polyakova found the similar bug on buildfarm [1] for REL_15_STABLE in the llvm build: -D_GNU_SOURCE -I/usr/include/libxml2 -flto=thin -emit-llvm -c -o segparse.bc segparse.c segparse.y:177:10: fatal error: 'segscan.c' file not found 177 | #include "segscan.c" | ^~~ 1 error generated Maybe backpatch [2] to all supported versions not just 16+? With the best regards, -- Anton A. Melnikov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company [1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=alligator&dt=2025-06-02%2019:07:06 [2] https://github.com/postgres/postgres/commit/16492df70bb25bc99ca3c340a75ba84ca64171b8
pgsql: Fix access-to-already-freed-memory issue in pgoutput.
Fix access-to-already-freed-memory issue in pgoutput. While pgoutput caches relation synchronization information in RelationSyncCache that resides in CacheMemoryContext, each entry's information (such as row filter expressions and column lists) is stored in the entry's private memory context (entry_cxt in RelationSyncEntry), which is a descendant memory context of the decoding context. If a logical decoding invoked via SQL functions like pg_logical_slot_get_binary_changes fails with an error, subsequent logical decoding executions could access already-freed memory of the entry's cache, resulting in a crash. With this change, it's ensured that RelationSyncCache is cleaned up even in error cases by using a memory context reset callback function. Backpatch to 15, where entry_cxt was introduced for column filtering and row filtering. While the backbranches v13 and v14 have a similar issue where RelationSyncCache persists even after an error when pgoutput is used via SQL API, we decided not to backport this fix. This decision was made because v13 is approaching its final minor release, and we won't have an chance to fix any new issues that might arise. Additionally, since using pgoutput via SQL API is not a common use case, the risk outwights the benefit. If we receive bug reports, we can consider backporting the fixes then. Author: vignesh C Co-authored-by: Masahiko Sawada Reviewed-by: Zhijie Hou Reviewed-by: Euler Taveira Discussion: https://postgr.es/m/CALDaNm0x-aCehgt8Bevs2cm=uhmwS28MvbYq1=s2ekf0adp...@mail.gmail.com Backpatch-through: 15 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c40761759fe48d146717694b0e21d2c231addc31 Modified Files -- src/backend/replication/pgoutput/pgoutput.c | 27 --- 1 file changed, 16 insertions(+), 11 deletions(-)
pgsql: Fix pg_dump sorting of foreign key constraints
Fix pg_dump sorting of foreign key constraints Apparently, commit 04bc2c42f765 failed to notice that DO_FK_CONSTRAINT objects require identical handling as DO_CONSTRAINT ones, which causes some pg_upgrade tests in debug builds to fail spuriously. Add that. Author: Álvaro Herrera Backpatch-through: 13 Discussion: https://postgr.es/m/[email protected] Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d20df9590aef652627b847421e874e77fef215d3 Modified Files -- src/bin/pg_dump/pg_dump_sort.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Fix determination of not-null constraint "locality" for inherite
Fix determination of not-null constraint "locality" for inherited columns It is possible to have a non-inherited not-null constraint on an inherited column, but we were failing to preserve such constraints during pg_upgrade where the source is 17 or older, because of a bug in the pg_dump query for it. Oversight in commit 14e87ffa5c54. Fix that query. In passing, touch-up a bogus nearby comment introduced by the same commit. In version 17, make the regression tests leave a table in this situation, so that this scenario is tested in the cross-version upgrade tests of 18 and up. Author: Dilip Kumar Reported-by: Andrew Bille Bug: #19074 Backpatch-through: 18 Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/615ff828e1cb8eaa2a987d4390c5c9970fc1a3e6 Modified Files -- src/bin/pg_dump/pg_dump.c | 8 +--- src/test/regress/expected/constraints.out | 4 src/test/regress/sql/constraints.sql | 5 + 3 files changed, 14 insertions(+), 3 deletions(-)
pgsql: Adjust new TAP test to work on macOS.
Adjust new TAP test to work on macOS. Seems Apple's version of "wc -l" puts spaces before the number. (I wonder why the cfbot didn't find this.) While here, make the failure case log what it got, to aid debugging future issues. Per buildfarm. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/afd532c3a80c12a9c0f836c5e4fc3cfe6503b91f Modified Files -- src/bin/psql/t/030_pager.pl | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-)
pgsql: Fix access-to-already-freed-memory issue in pgoutput.
Fix access-to-already-freed-memory issue in pgoutput. While pgoutput caches relation synchronization information in RelationSyncCache that resides in CacheMemoryContext, each entry's information (such as row filter expressions and column lists) is stored in the entry's private memory context (entry_cxt in RelationSyncEntry), which is a descendant memory context of the decoding context. If a logical decoding invoked via SQL functions like pg_logical_slot_get_binary_changes fails with an error, subsequent logical decoding executions could access already-freed memory of the entry's cache, resulting in a crash. With this change, it's ensured that RelationSyncCache is cleaned up even in error cases by using a memory context reset callback function. Backpatch to 15, where entry_cxt was introduced for column filtering and row filtering. While the backbranches v13 and v14 have a similar issue where RelationSyncCache persists even after an error when pgoutput is used via SQL API, we decided not to backport this fix. This decision was made because v13 is approaching its final minor release, and we won't have an chance to fix any new issues that might arise. Additionally, since using pgoutput via SQL API is not a common use case, the risk outwights the benefit. If we receive bug reports, we can consider backporting the fixes then. Author: vignesh C Co-authored-by: Masahiko Sawada Reviewed-by: Zhijie Hou Reviewed-by: Euler Taveira Discussion: https://postgr.es/m/CALDaNm0x-aCehgt8Bevs2cm=uhmwS28MvbYq1=s2ekf0adp...@mail.gmail.com Backpatch-through: 15 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b07682bce301d2236667ad45aeba61c671f81aae Modified Files -- src/backend/replication/pgoutput/pgoutput.c | 27 --- 1 file changed, 16 insertions(+), 11 deletions(-)
pgsql: Stop creating constraints during DETACH CONCURRENTLY
Stop creating constraints during DETACH CONCURRENTLY Commit 71f4c8c6f74b (which implemented DETACH CONCURRENTLY) added code to create a separate table constraint when a table is detached concurrently, identical to the partition constraint, on the theory that such a constraint was needed in case the optimizer had constructed any query plans that depended on the constraint being there. However, that theory was apparently bogus because any such plans would be invalidated. For hash partitioning, those constraints are problematic, because their expressions reference the OID of the parent partitioned table, to which the detached table is no longer related; this causes all sorts of problems (such as inability of restoring a pg_dump of that table, and the table no longer working properly if the partitioned table is later dropped). We'd like to get rid of all those constraints. In fact, for branch master, do that -- no longer create any substitute constraints. However, out of fear that some users might somehow depend on these constraints for other partitioning strategies, for stable branches (back to 14, which added DETACH CONCURRENTLY), only do it for hash partitioning. (If you repeatedly DETACH CONCURRENTLY and then ATTACH a partition, then with this constraint addition you don't need to scan the table in the ATTACH step, which presumably is good. But if users really valued this feature, they would have requested that it worked for non-concurrent DETACH also.) Author: Haiyang Li Reported-by: Fei Changhong Reported-by: Haiyang Li Backpatch-through: 14 Discussion: https://postgr.es/m/[email protected] Discussion: https://postgr.es/m/[email protected] Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/bdae98495660439655f1c89fb550a75d9ffb10ef Modified Files -- src/backend/commands/tablecmds.c | 14 +- src/test/regress/expected/alter_table.out | 8 src/test/regress/sql/alter_table.sql | 9 + 3 files changed, 26 insertions(+), 5 deletions(-)
pgsql: Remove overzealous _bt_killitems assertion.
Remove overzealous _bt_killitems assertion. An assertion in _bt_killitems expected the scan's currPos state to contain a valid LSN, saved from when currPos's page was initially read. The assertion failed to account for the fact that even logged relations can have leaf pages with an invalid LSN when built with wal_level set to "minimal". Remove the faulty assertion. Oversight in commit e6eed40e (though note that the assertion was backpatched to stable branches before 18 by commit 7c319f54). Author: Peter Geoghegan Reported-By: Matthijs van der Vleuten Bug: #19082 Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/314004021e549770d3d57fd0cf286050b948472d Modified Files -- src/backend/access/nbtree/nbtutils.c | 1 - 1 file changed, 1 deletion(-)
pgsql: Fix version number calculation for data folder flush in pg_combi
Fix version number calculation for data folder flush in pg_combinebackup The version number calculated by read_pg_version_file() is multiplied once by 1, to be able to do comparisons based on PG_VERSION_NUM or equivalents with a minor version included. However, the version number given sync_pgdata() was multiplied by 1 a second time, leading to an overestimated number. This issue was harmless (still incorrect) as pg_combinebackup does not support versions of Postgres older than v10, and sync_pgdata() only includes a version check due to the rename of pg_xlog/ to pg_wal/. This folder rename happened in the development cycle of v10. This would become a problem if in the future sync_pgdata() is changed to have more version-specific checks. Oversight in dc212340058b, so backpatch down to v17. Reviewed-by: Chao Li Discussion: https://postgr.es/m/[email protected] Backpatch-through: 17 Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a6598aac5295fcb169bd251cbc9fe125fa019a2d Modified Files -- src/bin/pg_combinebackup/pg_combinebackup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Remove state.tmp when failing to save a replication slot
Remove state.tmp when failing to save a replication slot An error happening while a slot data is saved on disk in SaveSlotToPath() could cause a state.tmp file (temporary file holding the slot state data, renamed to its permanent name at the end of the function) to remain around after it has been created. This temporary file is created with O_EXCL, meaning that if an existing state.tmp is found, its creation would fail. This would prevent the slot data to be saved, requiring a manual intervention to remove state.tmp before being able to save again a slot. Possible scenarios where this temporary file could remain on disk is for example a ENOSPC case (no disk space) while writing, syncing or renaming it. The bug reports point to a write failure as the principal cause of the problems. Using O_TRUNC has been argued back in 2019 as a potential solution to discard any temporary file that could exist. This solution was rejected as O_EXCL can also act as a safety measure when saving the slot state, crash recovery offering cleanup guarantees post-crash. This commit uses the alternative approach that has been suggested by Andres Freund back in 2019. When the temporary state file cannot be written, synced, closed or renamed (note: not when created!), an unlink() is used to remove the temporary state file while holding the in-progress I/O LWLock, so as any follow-up attempts to save a slot's data would not choke on an existing file that remained around because of a previous failure. This problem has been reported a few times across the years, going back to 2019, but for some reason I have never come back to do something about it and it has been forgotten. A recent report has reminded me that this was still a problem. Reported-by: Kevin K Biju Reported-by: Sergei Kornilov Reported-by: Grigory Smolkin Discussion: https://postgr.es/m/cam45keha32sokl_g8vk38cwvtbeooxcsxapas7jt7yprf2m...@mail.gmail.com Discussion: https://postgr.es/m/[email protected] Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f57f2760e6651bb51bf99189e25a29ab4507860d Modified Files -- src/backend/replication/slot.c | 7 +++ 1 file changed, 7 insertions(+)
pgsql: Fix update-po for the PGXS case
Fix update-po for the PGXS case The original formulation failed to take into account the fact that for the PGXS case, the source dir is not $(top_srcdir), so it ended up not doing anything. Handle it explicitly. Author: Ryo Matsumura Reviewed-by: Bryan Green Backpatch-through: 13 Discussion: https://postgr.es/m/tycpr01mb113164770fb0b0be6ed21e68ee8...@tycpr01mb11316.jpnprd01.prod.outlook.com Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/33202cba8db39e5c9001dbd11b857d52096606a2 Modified Files -- src/nls-global.mk | 5 + 1 file changed, 5 insertions(+)
pgsql: Fix matching check in recovery test 042_low_level_backup
Fix matching check in recovery test 042_low_level_backup 042_low_level_backup compared the result of a query two times with a comparison operator based on an integer, while the result should be compared with a string. The outcome of the tests is currently not impacted by this change. However, it could be possible that the tests fail to detect future issues if the query results become different, for some reason. Oversight in 99b4a63bef94. Author: Sadhuprasad Patro Discussion: https://postgr.es/m/caff0-chhwnx_cv2uy7tkjodubeogprjpw4rpf1jqb16_1bu...@mail.gmail.com Backpatch-through: 17 Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/61b5fa029a432e6c5f516c633b5467d4cc55f264 Modified Files -- src/test/recovery/t/042_low_level_backup.pl | 8 1 file changed, 4 insertions(+), 4 deletions(-)
pgsql: Override log_error_verbosity to "default" in test 009_log_temp_f
Override log_error_verbosity to "default" in test 009_log_temp_files Per report from buildfarm member prion. The CI does not use this parameter, and this buildfarm member sets log_error_verbosity to "verbose". This would generate extra LOCATION entries in the logs, causing the regexps of the test to fail. Trying to support log_error_verbosity=verbose in the test would mean to tweak all the regexps used in the test to detect an optional set of LOCATION lines, at least. This would not improve the coverage, and forcing the GUC value is simpler. Oversight in 76bba033128a. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/02c171f63fca870d55c4b184a4b7c0cebb06faa1 Modified Files -- src/test/modules/test_misc/t/009_log_temp_files.pl | 1 + 1 file changed, 1 insertion(+)
pgsql: Fix issue with reading zero bytes in Gzip_read.
Fix issue with reading zero bytes in Gzip_read. pg_dump expects a read request of zero bytes to be a no-op; see for example ReadStr(). Gzip_read got this wrong and falsely supposed that the resulting gzret == 0 indicated an error. We could complicate that error-checking logic some more, but it seems best to just fall out immediately when passed size == 0. This bug breaks the nominally-supported case of manually gzip'ing the toc.dat file within a directory-style dump, so back-patch to v16 where this code came in. (Prior branches already have a short-circuit for size == 0 before their only gzread call.) Author: Tom Lane Reviewed-by: Chao Li Discussion: https://postgr.es/m/[email protected] Backpatch-through: 16 Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/bf18e9bd70decd294a9be517cb5b3a260ccfdd15 Modified Files -- src/bin/pg_dump/compress_gzip.c | 4 1 file changed, 4 insertions(+)
pgsql: dbase_redo: Fix Valgrind-reported memory leak
dbase_redo: Fix Valgrind-reported memory leak Introduced by my (Álvaro's) commit 9e4f914b5eba, which was itself backpatched to pg10, though only pg15 and up contain the problem because of commit 9c08aea6a309. This isn't a particularly significant leak, but given the fix is trivial, we might as well backpatch to all branches where it applies, so do that. Author: Nathan Bossart Reported-by: Andres Freund Discussion: https://postgr.es/m/x4odfdlrwvsjawscnqsqjpofvauxslw7b4oyvxgt5owoyf4ysn@heafjusodrz7 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ff47f9c16c2f626d828a473d63c90d03f18a34a3 Modified Files -- src/backend/commands/dbcommands.c | 1 + 1 file changed, 1 insertion(+)
pgsql: Use SOCK_ERRNO[_SET] in fe-secure-gssapi.c.
Use SOCK_ERRNO[_SET] in fe-secure-gssapi.c. On Windows, this code did not handle error conditions correctly at all, since it looked at "errno" which is not used for socket-related errors on that platform. This resulted, for example, in failure to connect to a PostgreSQL server with GSSAPI enabled. We have a convention for dealing with this within libpq, which is to use SOCK_ERRNO and SOCK_ERRNO_SET rather than touching errno directly; but the GSSAPI code is a relative latecomer and did not get that memo. (The equivalent backend code continues to use errno, because the backend does this differently. Maybe libpq's approach should be rethought someday.) Apparently nobody tries to build libpq with GSSAPI support on Windows, or we'd have heard about this before, because it's been broken all along. Back-patch to all supported branches. Author: Ning Wu Co-authored-by: Tom Lane Discussion: https://postgr.es/m/CAFGqpvg-pRw=cdsupkyfwy6d3d-m9tw8wmcaee7hhwfm-oy...@mail.gmail.com Backpatch-through: 13 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f46d77377b9a0be25524a6339296c8a892059f2c Modified Files -- src/interfaces/libpq/fe-secure-gssapi.c | 27 +++ 1 file changed, 15 insertions(+), 12 deletions(-)
pgsql: Fix comment in eager_aggregate.sql
Fix comment in eager_aggregate.sql The comment stated that eager aggregation is disabled by default, which is no longer true. This patch removes that comment as well as the related GUC set statement. Reported-by: David Rowley Discussion: https://postgr.es/m/caaphdvr4ywpimr3rsgywjwv-u8xorqtakriyy9zuszjzoqg...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/36fd8bde1b77191eaf7d3499052c0636b6b93a87 Modified Files -- src/test/regress/expected/eager_aggregate.out | 2 -- src/test/regress/sql/eager_aggregate.sql | 3 --- 2 files changed, 5 deletions(-)
pgsql: docs: Fix protocol version 3.2 message format of CancelRequest
docs: Fix protocol version 3.2 message format of CancelRequest Since protocol version 3.2 the CancelRequest does not have a fixed size length anymore. The protocol docs still listed the length field to be a constant number though. This fixes that. Author: Jelte Fennema-Nio Reported-by: Dmitry Igrishin Backpatch-through: 18 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d3ba50db48e66be8804b9edf093b0f921d625425 Modified Files -- doc/src/sgml/protocol.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Fix determination of not-null constraint "locality" for inherite
Fix determination of not-null constraint "locality" for inherited columns It is possible to have a non-inherited not-null constraint on an inherited column, but we were failing to preserve such constraints during pg_upgrade where the source is 17 or older, because of a bug in the pg_dump query for it. Oversight in commit 14e87ffa5c54. Fix that query. In passing, touch-up a bogus nearby comment introduced by the same commit. In version 17, make the regression tests leave a table in this situation, so that this scenario is tested in the cross-version upgrade tests of 18 and up. Author: Dilip Kumar Reported-by: Andrew Bille Bug: #19074 Backpatch-through: 18 Discussion: https://postgr.es/m/[email protected] Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0fe07fa115f520a67b9a9180cea703e91d8c7ac4 Modified Files -- src/bin/pg_dump/pg_dump.c | 8 +--- src/test/regress/expected/constraints.out | 4 src/test/regress/sql/constraints.sql | 5 + 3 files changed, 14 insertions(+), 3 deletions(-)
pgsql: Fix determination of not-null constraint "locality" for inherite
Fix determination of not-null constraint "locality" for inherited columns It is possible to have a non-inherited not-null constraint on an inherited column, but we were failing to preserve such constraints during pg_upgrade where the source is 17 or older, because of a bug in the pg_dump query for it. Oversight in commit 14e87ffa5c54. Fix that query. In passing, touch-up a bogus nearby comment introduced by the same commit. In version 17, make the regression tests leave a table in this situation, so that this scenario is tested in the cross-version upgrade tests of 18 and up. Author: Dilip Kumar Reported-by: Andrew Bille Bug: #19074 Backpatch-through: 18 Discussion: https://postgr.es/m/[email protected] Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c945b06d5f03e30cec279df516688c70787b2b2c Modified Files -- src/test/regress/expected/constraints.out | 4 src/test/regress/sql/constraints.sql | 5 + 2 files changed, 9 insertions(+)
pgsql: Use ereport rather than elog in WinCheckAndInitializeNullTreatme
Use ereport rather than elog in WinCheckAndInitializeNullTreatment. Previously WinCheckAndInitializeNullTreatment() used elog() to emit an error message. ereport() should be used instead because it's a user-facing error. Also use existing get_func_name() to get a function's name, rather than own implementation. Moreover add an assertion to validate winobj parameter, just like other window function API. Reported-by: Tom Lane Author: Tatsuo Ishii Reviewed-by: Chao Li Discussion: https://postgr.es/m/2952409.1760023154%40sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/5f3808646f67260d5dc0d95f2602886da5cf5c52 Modified Files -- src/backend/executor/nodeWindowAgg.c | 20 1 file changed, 8 insertions(+), 12 deletions(-)
pgsql: Fix pg_dump sorting of foreign key constraints
Fix pg_dump sorting of foreign key constraints Apparently, commit 04bc2c42f765 failed to notice that DO_FK_CONSTRAINT objects require identical handling as DO_CONSTRAINT ones, which causes some pg_upgrade tests in debug builds to fail spuriously. Add that. Author: Álvaro Herrera Backpatch-through: 13 Discussion: https://postgr.es/m/[email protected] Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4cc3b4445913d962087deccdc0cdec4910bcbfca Modified Files -- src/bin/pg_dump/pg_dump_sort.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Remove preprocessor guards from injection points
Remove preprocessor guards from injection points When defining an injection point there is no need to wrap the definition with USE_INJECTION_POINT guards, the INJECTION_POINT macro is available in all builds. Remove to make the code consistent. Author: Hayato Kuroda Reviewed-by: Michael Paquier Reviewed-by: Daniel Gustafsson Discussion: https://postgr.es/m/oscpr01mb14966c8015deb05abef2ce077f5...@oscpr01mb14966.jpnprd01.prod.outlook.com Backpatch-through: 17 Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/53a2246ddf9b1e641654dd0654ff8f24e952920a Modified Files -- src/backend/access/transam/xlog.c | 2 -- 1 file changed, 2 deletions(-)
pgsql: Fix pg_dump sorting of foreign key constraints
Fix pg_dump sorting of foreign key constraints Apparently, commit 04bc2c42f765 failed to notice that DO_FK_CONSTRAINT objects require identical handling as DO_CONSTRAINT ones, which causes some pg_upgrade tests in debug builds to fail spuriously. Add that. Author: Álvaro Herrera Backpatch-through: 13 Discussion: https://postgr.es/m/[email protected] Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/162e70ea06eb31dfe8f75bf508afde323eb0b077 Modified Files -- src/bin/pg_dump/pg_dump_sort.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Stop creating constraints during DETACH CONCURRENTLY
Stop creating constraints during DETACH CONCURRENTLY Commit 71f4c8c6f74b (which implemented DETACH CONCURRENTLY) added code to create a separate table constraint when a table is detached concurrently, identical to the partition constraint, on the theory that such a constraint was needed in case the optimizer had constructed any query plans that depended on the constraint being there. However, that theory was apparently bogus because any such plans would be invalidated. For hash partitioning, those constraints are problematic, because their expressions reference the OID of the parent partitioned table, to which the detached table is no longer related; this causes all sorts of problems (such as inability of restoring a pg_dump of that table, and the table no longer working properly if the partitioned table is later dropped). We'd like to get rid of all those constraints. In fact, for branch master, do that -- no longer create any substitute constraints. However, out of fear that some users might somehow depend on these constraints for other partitioning strategies, for stable branches (back to 14, which added DETACH CONCURRENTLY), only do it for hash partitioning. (If you repeatedly DETACH CONCURRENTLY and then ATTACH a partition, then with this constraint addition you don't need to scan the table in the ATTACH step, which presumably is good. But if users really valued this feature, they would have requested that it worked for non-concurrent DETACH also.) Author: Haiyang Li Reported-by: Fei Changhong Reported-by: Haiyang Li Backpatch-through: 14 Discussion: https://postgr.es/m/[email protected] Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/3231fd0455220194d6f75323c83819a38fc0a382 Modified Files -- src/backend/commands/tablecmds.c | 50 --- src/test/regress/expected/alter_table.out | 28 + src/test/regress/sql/alter_table.sql | 15 ++ 3 files changed, 17 insertions(+), 76 deletions(-)
pgsql: Assign each subquery a unique name prior to planning it.
Assign each subquery a unique name prior to planning it. Previously, subqueries were given names only after they were planned, which makes it difficult to use information from a previous execution of the query to guide future planning. If, for example, you knew something about how you want "InitPlan 2" to be planned, you won't know whether the subquery you're currently planning will end up being "InitPlan 2" until after you've finished planning it, by which point it's too late to use the information that you had. To fix this, assign each subplan a unique name before we begin planning it. To improve consistency, use textual names for all subplans, rather than, as we did previously, a mix of numbers (such as "InitPlan 1") and names (such as "CTE foo"), and make sure that the same name is never assigned more than once. We adopt the somewhat arbitrary convention of using the type of sublink to set the plan name; for example, a query that previously had two expression sublinks shown as InitPlan 2 and InitPlan 1 will now end up named expr_1 and expr_2. Because names are assigned before rather than after planning, some of the regression test outputs show the numerical part of the name switching positions: what was previously SubPlan 2 was actually the first one encountered, but we finished planning it later. We assign names even to subqueries that aren't shown as such within the EXPLAIN output. These include subqueries that are a FROM clause item or a branch of a set operation, rather than something that will be turned into an InitPlan or SubPlan. The purpose of this is to make sure that, below the topmost query level, there's always a name for each subquery that is stable from one planning cycle to the next (assuming no changes to the query or the database schema). Author: Robert Haas Co-authored-by: Tom Lane Reviewed-by: Alexandra Wang Reviewed-by: Richard Guo Reviewed-by: Tom Lane Reviewed-by: Junwang Zhao Discussion: http://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8c49a484e8ebb0199fba4bd68eaaedaf49b48ed0 Modified Files -- contrib/postgres_fdw/expected/postgres_fdw.out | 70 +++--- src/backend/commands/explain.c | 15 +- src/backend/optimizer/path/allpaths.c | 6 +- src/backend/optimizer/plan/planagg.c | 3 + src/backend/optimizer/plan/planner.c | 78 ++- src/backend/optimizer/plan/subselect.c | 87 --- src/backend/optimizer/prep/prepjointree.c | 1 + src/backend/optimizer/prep/prepunion.c | 5 +- src/backend/utils/adt/ruleutils.c | 33 ++- src/include/nodes/pathnodes.h | 6 + src/include/nodes/primnodes.h | 1 + src/include/optimizer/planner.h| 4 + src/test/regress/expected/aggregates.out | 58 ++--- src/test/regress/expected/create_index.out | 14 +- src/test/regress/expected/groupingsets.out | 94 src/test/regress/expected/incremental_sort.out | 8 +- src/test/regress/expected/inherit.out | 32 +-- src/test/regress/expected/insert_conflict.out | 4 +- src/test/regress/expected/join.out | 78 +++ src/test/regress/expected/join_hash.out| 32 +-- src/test/regress/expected/memoize.out | 4 +- src/test/regress/expected/merge.out| 12 +- src/test/regress/expected/partition_prune.out | 300 - src/test/regress/expected/portals.out | 12 +- src/test/regress/expected/predicate.out| 8 +- src/test/regress/expected/returning.out| 24 +- src/test/regress/expected/rowsecurity.out | 138 ++-- src/test/regress/expected/rowtypes.out | 12 +- src/test/regress/expected/select_parallel.out | 56 ++--- src/test/regress/expected/sqljson.out | 4 +- src/test/regress/expected/subselect.out| 174 +++--- src/test/regress/expected/updatable_views.out | 52 ++--- src/test/regress/expected/update.out | 8 +- src/test/regress/expected/window.out | 10 +- src/test/regress/expected/with.out | 20 +- 35 files changed, 810 insertions(+), 653 deletions(-)
pgsql: Fix pg_dump sorting of foreign key constraints
Fix pg_dump sorting of foreign key constraints Apparently, commit 04bc2c42f765 failed to notice that DO_FK_CONSTRAINT objects require identical handling as DO_CONSTRAINT ones, which causes some pg_upgrade tests in debug builds to fail spuriously. Add that. Author: Álvaro Herrera Backpatch-through: 13 Discussion: https://postgr.es/m/[email protected] Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/6062c3db3093d92d6240b88c6818d0e7aaa73341 Modified Files -- src/bin/pg_dump/pg_dump_sort.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Fix pg_dump sorting of foreign key constraints
Fix pg_dump sorting of foreign key constraints Apparently, commit 04bc2c42f765 failed to notice that DO_FK_CONSTRAINT objects require identical handling as DO_CONSTRAINT ones, which causes some pg_upgrade tests in debug builds to fail spuriously. Add that. Author: Álvaro Herrera Backpatch-through: 13 Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/4921a5972a345fd3118f47a9e425ec862d8a8333 Modified Files -- src/bin/pg_dump/pg_dump_sort.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Fix pg_dump sorting of foreign key constraints
Fix pg_dump sorting of foreign key constraints Apparently, commit 04bc2c42f765 failed to notice that DO_FK_CONSTRAINT objects require identical handling as DO_CONSTRAINT ones, which causes some pg_upgrade tests in debug builds to fail spuriously. Add that. Author: Álvaro Herrera Backpatch-through: 13 Discussion: https://postgr.es/m/[email protected] Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/06c1ee6b75dc040b2444535240d6f0bbee25c977 Modified Files -- src/bin/pg_dump/pg_dump_sort.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Fix pg_dump sorting of foreign key constraints
Fix pg_dump sorting of foreign key constraints Apparently, commit 04bc2c42f765 failed to notice that DO_FK_CONSTRAINT objects require identical handling as DO_CONSTRAINT ones, which causes some pg_upgrade tests in debug builds to fail spuriously. Add that. Author: Álvaro Herrera Backpatch-through: 13 Discussion: https://postgr.es/m/[email protected] Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7419c99a25fb0f6138062ebbc15d61e57437 Modified Files -- src/bin/pg_dump/pg_dump_sort.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Avoid warnings in tests when openssl binary isn't available
Avoid warnings in tests when openssl binary isn't available The SSL tests for pg_stat_ssl tries to exactly match the serial from the certificate by extracting it with the openssl binary. If that fails due to the binary not being available, a fallback match is used, but the attempt to execute a missing binary adds a warning to the output which can confuse readers for a failure in the test. Fix by only attempting if the openssl binary was found by autoconf/meson. Backpatch down to v16 where commit c8e4030d1bdd made the test use the OPENSSL variable from autoconf/meson instead of a hard- coded value. Author: Daniel Gustafsson Reported-by: Christoph Berg Discussion: https://postgr.es/m/[email protected] Backpatch-through: 16 Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f01c4eb4e901522859367ddfef69098224b36321 Modified Files -- src/test/ssl/t/001_ssltests.pl | 42 +++--- 1 file changed, 19 insertions(+), 23 deletions(-)
pgsql: Add log_autoanalyze_min_duration
Add log_autoanalyze_min_duration The log output functionality of log_autovacuum_min_duration applies to both VACUUM and ANALYZE, so it is not possible to separate the VACUUM and ANALYZE log output thresholds. Logs are likely to be output only for VACUUM and not for ANALYZE. Therefore, we decided to separate the threshold for log output of VACUUM by autovacuum (log_autovacuum_min_duration) and the threshold for log output of ANALYZE by autovacuum (log_autoanalyze_min_duration). Author: Shinya Kato Reviewed-by: Kasahara Tatsuhito Discussion: https://www.postgresql.org/message-id/flat/caozeurqtfv4mxjiwt-xdnimeezay+rgzvsle8ysyekhzcaj...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/dd3ae378301f7e84c18f7a90f183c3cd4165c0da Modified Files -- doc/src/sgml/config.sgml | 41 ++- doc/src/sgml/maintenance.sgml | 3 +- doc/src/sgml/ref/create_table.sgml| 15 ++ src/backend/access/common/reloptions.c| 15 -- src/backend/access/heap/vacuumlazy.c | 6 ++-- src/backend/commands/analyze.c| 8 +++--- src/backend/commands/vacuum.c | 10 +-- src/backend/postmaster/autovacuum.c | 16 --- src/backend/utils/misc/guc_parameters.dat | 14 +++-- src/backend/utils/misc/postgresql.conf.sample | 7 - src/bin/psql/tab-complete.in.c| 1 + src/include/commands/vacuum.h | 11 +-- src/include/postmaster/autovacuum.h | 1 + src/include/utils/rel.h | 3 +- src/test/regress/pg_regress.c | 1 + src/tools/ci/pg_ci_base.conf | 1 + 16 files changed, 122 insertions(+), 31 deletions(-)
pgsql: Add helper for freeze determination to heap_page_prune_and_freez
Add helper for freeze determination to heap_page_prune_and_freeze After scanning the line pointers on a heap page during the first phase of vacuum, we use the information collected to decide whether to use the assembled freeze plans. Move this decision logic into a helper function to improve readability. While here, rename a PruneState member and disambiguate some local variables in heap_page_prune_and_freeze(). Author: Melanie Plageman Reviewed-by: Andres Freund Discussion: https://postgr.es/m/2wk7jo4m4qwh5sn33pfgerdjfujebbccsmmlownybddbh6nawl%40mdyyqpqzxjek Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c8dd6542bae42744c676234dca45972e2cc3dfb2 Modified Files -- src/backend/access/heap/pruneheap.c | 221 +--- 1 file changed, 131 insertions(+), 90 deletions(-)
pgsql: Revert "pg_createsubscriber: Add log message when no publication
Revert "pg_createsubscriber: Add log message when no publications exist to drop." This reverts commit 74ac377d75135e02064fc4427bec401277b4f60c. The previous change contained a misconception about how publications are cleaned up on the subscriber. The newly added log message could confuse users, particularly when running pg_createsubscriber with --dry-run - users would see a "dropping publication" message immediately followed by a "no publications found" message. Discussion: https://postgr.es/m/CAHut+Pu7xz1LqNvyQyvSHrV0Sw6D=e6T-Jm=gh1mrjrkuwg...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/45a7faf130176ae7c152413967c7c90068476a94 Modified Files -- src/bin/pg_basebackup/pg_createsubscriber.c | 13 - 1 file changed, 4 insertions(+), 9 deletions(-)
Re: pgsql: Fix EPQ crash from missing partition directory in EState
On Thu, Oct 16, 2025 at 2:03 PM Amit Langote wrote: > Fix EPQ crash from missing partition directory in EState > > EvalPlanQualStart() failed to propagate es_partition_directory into > the child EState used for EPQ rechecks. When execution time partition > pruning ran during the EPQ scan, executor code dereferenced a NULL > partition directory and crashed. > > Previously, propagating es_partition_directory into the EPQ EState was > unnecessary because CreatePartitionPruneState(), which sets it on > demand, also initialized the exec-pruning context. After commit > d47cbf474, Oops, that could’ve been worded better -- I meant “Prior to d47cbf474” rather than “Previously”. -- Thanks, Amit Langote
pgsql: Fix two comments in numeric.c
Fix two comments in numeric.c The comments at the top of numeric_int4_safe() and numeric_int8_safe() mentioned respectively int4_numeric() and int8_numeric(). The intention is to refer to numeric_int4() and numeric_int8(). Oversights in 4246a977bad6. Reported-by: jian he Discussion: https://postgr.es/m/CACJufxFfVt7Jx9_j=juxxyp-6tznn8ocvs9e-qsgp0brd8k...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0c7f103028202cec94e12cbe45cebdb5c8fbc392 Modified Files -- src/backend/utils/adt/numeric.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Optimize hex_encode() and hex_decode() using SIMD.
Optimize hex_encode() and hex_decode() using SIMD. The hex_encode() and hex_decode() functions serve as the workhorses for hexadecimal data for bytea's text format conversion functions, and some workloads are sensitive to their performance. This commit adds new implementations that use routines from port/simd.h, which testing indicates are much faster for larger inputs. For small or invalid inputs, we fall back on the existing scalar versions. Since we are using port/simd.h, these optimizations apply to both x86-64 and AArch64. Author: Nathan Bossart Co-authored-by: Chiranmoy Bhattacharya Co-authored-by: Susmitha Devanga Reviewed-by: John Naylor Discussion: https://postgr.es/m/aLhVWTRy0QPbW2tl%40nathan Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ec8719ccbfcd78c6b40b5f2b94f60769f3bd08aa Modified Files -- src/backend/utils/adt/encode.c| 137 +- src/include/port/simd.h | 211 ++ src/test/regress/expected/strings.out | 58 ++ src/test/regress/sql/strings.sql | 16 +++ 4 files changed, 418 insertions(+), 4 deletions(-)
pgsql: Add extension_state member to PlannedStmt.
Add extension_state member to PlannedStmt. Extensions can stash data computed at plan time into this list using planner_shutdown_hook (or perhaps other mechanisms) and then access it from any code that has access to the PlannedStmt (such as explain hooks), allowing for extensible debugging and instrumentation of plans. Reviewed-by: Andrei Lepikhov Reviewed-by: Tom Lane Discussion: http://postgr.es/m/ca+tgmoywkhu2hkr62toyzh-ktdenmdelw7gkoonjl-tnouq...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/4685977cc51c91dda0f76b1ef71ba02823a57a1e Modified Files -- src/include/nodes/plannodes.h | 9 + 1 file changed, 9 insertions(+)
pgsql: ecpg: check return value of replace_variables()
ecpg: check return value of replace_variables() The function returns false if it fails to allocate memory, so make sure to check the return value in callsites. Author: Aleksander Alekseev Reviewed-by: Daniel Gustafsson Discussion: https://postgr.es/m/caj7c6tnpru8zxgdfn3pygy1tzo0bgszx+kkqw0z7zt3heyc...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0d82163958005b2ba56f8c58311888d142fa4509 Modified Files -- src/interfaces/ecpg/ecpglib/prepare.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-)
pgsql: pgbench: Fix error reporting in readCommandResponse().
pgbench: Fix error reporting in readCommandResponse(). pgbench uses readCommandResponse() to process server responses. When readCommandResponse() encounters an error during a call to PQgetResult() to fetch the current result, it attempts to report it with an additional error message from PQerrorMessage(). However, previously, this extra error message could be lost or become incorrect. The cause was that after fetching the current result (and detecting an error), readCommandResponse() called PQgetResult() again to peek at the next result. This second call could overwrite the libpq connection's error message before the original error was reported, causing the error message retrieved from PQerrorMessage() to be lost or overwritten. This commit fixes the issue by updating readCommandResponse() to use PQresultErrorMessage() instead of PQerrorMessage() to retrieve the error message generated when the PQgetResult() for the current result causes an error, ensuring the correct message is reported. Backpatch to all supported versions. Author: Yugo Nagata Reviewed-by: Chao Li Reviewed-by: Fujii Masao Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7d7e81d1e6b8cff9b8e6047609df2b8fbf8d76f3 Modified Files -- src/bin/pgbench/pgbench.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Improve planner's width estimates for set operations
Improve planner's width estimates for set operations For UNION, EXCEPT and INTERSECT, we were not very good at estimating the PathTarget.width for the set operation. Since the targetlist of the set operation is made up of Vars with varno==0, this would result in get_expr_width() applying a default estimate based on the Var's type rather than taking width estimates from any relation's statistics. Here we attempt to improve the situation by looking at the width estimates for the set operation child paths and calculating the average width of the relevant child paths weighted over the estimated number of rows. For UNION and INTERSECT, the relevant paths to look at are *all* child paths. For EXCEPT, since we don't return rows from the right-hand child (only possibly remove left-hand rows matching those), we use only the left-hand child for width estimates. This also adjusts the hashed-UNION Path's PathTarget to use the same PathTarget as its Append subpath. Both PathTargets will be the same and are void of any resjunk columns, per generate_append_tlist(). Making the AggPath use the same PathTarget saves having to adjust the "width" of the AggPath's PathTarget too. This was reported as a bug by sunw.fnst, but it's not something we ever claimed to do properly. Plus, if we were to adjust this in back branches, plans could change as the estimated input sizes to Sorts and Hash Aggregates could go up or down. Plan choices aren't something we want to destabilize in stable versions. Reported-by: sunw.fnst <[email protected]> Author: David Rowley Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/2cb49c609bd9bf44d319591df7bef1eb107cb375 Modified Files -- src/backend/optimizer/prep/prepunion.c | 59 +++--- 1 file changed, 55 insertions(+), 4 deletions(-)
pgsql: Implement Eager Aggregation
Implement Eager Aggregation Eager aggregation is a query optimization technique that partially pushes aggregation past a join, and finalizes it once all the relations are joined. Eager aggregation may reduce the number of input rows to the join and thus could result in a better overall plan. In the current planner architecture, the separation between the scan/join planning phase and the post-scan/join phase means that aggregation steps are not visible when constructing the join tree, limiting the planner's ability to exploit aggregation-aware optimizations. To implement eager aggregation, we collect information about aggregate functions in the targetlist and HAVING clause, along with grouping expressions from the GROUP BY clause, and store it in the PlannerInfo node. During the scan/join planning phase, this information is used to evaluate each base or join relation to determine whether eager aggregation can be applied. If applicable, we create a separate RelOptInfo, referred to as a grouped relation, to represent the partially-aggregated version of the relation and generate grouped paths for it. Grouped relation paths can be generated in two ways. The first method involves adding sorted and hashed partial aggregation paths on top of the non-grouped paths. To limit planning time, we only consider the cheapest or suitably-sorted non-grouped paths in this step. Alternatively, grouped paths can be generated by joining a grouped relation with a non-grouped relation. Joining two grouped relations is currently not supported. To further limit planning time, we currently adopt a strategy where partial aggregation is pushed only to the lowest feasible level in the join tree where it provides a significant reduction in row count. This strategy also helps ensure that all grouped paths for the same grouped relation produce the same set of rows, which is important to support a fundamental assumption of the planner. For the partial aggregation that is pushed down to a non-aggregated relation, we need to consider all expressions from this relation that are involved in upper join clauses and include them in the grouping keys, using compatible operators. This is essential to ensure that an aggregated row from the partial aggregation matches the other side of the join if and only if each row in the partial group does. This ensures that all rows within the same partial group share the same "destiny", which is crucial for maintaining correctness. One restriction is that we cannot push partial aggregation down to a relation that is in the nullable side of an outer join, because the NULL-extended rows produced by the outer join would not be available when we perform the partial aggregation, while with a non-eager-aggregation plan these rows are available for the top-level aggregation. Pushing partial aggregation in this case may result in the rows being grouped differently than expected, or produce incorrect values from the aggregate functions. If we have generated a grouped relation for the topmost join relation, we finalize its paths at the end. The final paths will compete in the usual way with paths built from regular planning. The patch was originally proposed by Antonin Houska in 2017. This commit reworks various important aspects and rewrites most of the current code. However, the original patch and reviews were very useful. Author: Richard Guo Author: Antonin Houska (in an older version) Reviewed-by: Robert Haas Reviewed-by: Jian He Reviewed-by: Tender Wang Reviewed-by: Matheus Alcantara Reviewed-by: Tom Lane Reviewed-by: David Rowley Reviewed-by: Tomas Vondra (in an older version) Reviewed-by: Andy Fan (in an older version) Reviewed-by: Ashutosh Bapat (in an older version) Discussion: https://postgr.es/m/cambws48jzlrpt1j_00zcpzxwuqkawqofe8roc-adiyqsqrp...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8e11859102f947e6145acdd809e5cdcdfbe90fa5 Modified Files -- contrib/postgres_fdw/expected/postgres_fdw.out| 49 +- doc/src/sgml/config.sgml | 31 + src/backend/optimizer/README | 110 ++ src/backend/optimizer/geqo/geqo_eval.c| 21 +- src/backend/optimizer/path/allpaths.c | 467 +- src/backend/optimizer/path/joinrels.c | 193 +++ src/backend/optimizer/plan/initsplan.c| 370 + src/backend/optimizer/plan/planmain.c |9 + src/backend/optimizer/plan/planner.c | 124 +- src/backend/optimizer/util/appendinfo.c | 51 + src/backend/optimizer/util/relnode.c | 650 src/backend/utils/misc/guc_parameters.dat | 16 + src/backend/utils/misc/postgresql.conf.sample |2 + src/include/nodes/pathnodes.h | 117 ++ src/include/optimizer/pathnode.h |4 + src/include/optimizer/paths.h |4 + src/include/optimi
pgsql: Use SOCK_ERRNO[_SET] in fe-secure-gssapi.c.
Use SOCK_ERRNO[_SET] in fe-secure-gssapi.c. On Windows, this code did not handle error conditions correctly at all, since it looked at "errno" which is not used for socket-related errors on that platform. This resulted, for example, in failure to connect to a PostgreSQL server with GSSAPI enabled. We have a convention for dealing with this within libpq, which is to use SOCK_ERRNO and SOCK_ERRNO_SET rather than touching errno directly; but the GSSAPI code is a relative latecomer and did not get that memo. (The equivalent backend code continues to use errno, because the backend does this differently. Maybe libpq's approach should be rethought someday.) Apparently nobody tries to build libpq with GSSAPI support on Windows, or we'd have heard about this before, because it's been broken all along. Back-patch to all supported branches. Author: Ning Wu Co-authored-by: Tom Lane Discussion: https://postgr.es/m/CAFGqpvg-pRw=cdsupkyfwy6d3d-m9tw8wmcaee7hhwfm-oy...@mail.gmail.com Backpatch-through: 13 Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d83879a32b481f0e23cd8a14f7849cff3f8898b5 Modified Files -- src/interfaces/libpq/fe-secure-gssapi.c | 27 +++ 1 file changed, 15 insertions(+), 12 deletions(-)
pgsql: Avoid warnings in tests when openssl binary isn't available
Avoid warnings in tests when openssl binary isn't available The SSL tests for pg_stat_ssl tries to exactly match the serial from the certificate by extracting it with the openssl binary. If that fails due to the binary not being available, a fallback match is used, but the attempt to execute a missing binary adds a warning to the output which can confuse readers for a failure in the test. Fix by only attempting if the openssl binary was found by autoconf/meson. Backpatch down to v16 where commit c8e4030d1bdd made the test use the OPENSSL variable from autoconf/meson instead of a hard- coded value. Author: Daniel Gustafsson Reported-by: Christoph Berg Discussion: https://postgr.es/m/[email protected] Backpatch-through: 16 Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/150a1b328778b1594f543057b6d3fbb78178f8b2 Modified Files -- src/test/ssl/t/001_ssltests.pl | 42 +++--- 1 file changed, 19 insertions(+), 23 deletions(-)
pgsql: Allow role created by new test to log in on Windows.
Allow role created by new test to log in on Windows. We must tell init about each role name we plan to connect as, else SSPI auth fails. Similar to previous patches such as 14793f471, 973542866. Oversight in 208927e65, per buildfarm member drongo. (Although that was back-patched to v13, the test script only exists in v16 and up.) Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c29d32d27bd3ef09fd7c4c372d2be18f4b8ad195 Modified Files -- contrib/pg_prewarm/t/001_basic.pl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Allow role created by new test to log in on Windows.
Allow role created by new test to log in on Windows. We must tell init about each role name we plan to connect as, else SSPI auth fails. Similar to previous patches such as 14793f471, 973542866. Oversight in 208927e65, per buildfarm member drongo. (Although that was back-patched to v13, the test script only exists in v16 and up.) Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d4e8c37cca39362b4281ce254f92ff2fe5a4b4b0 Modified Files -- contrib/pg_prewarm/t/001_basic.pl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Allow role created by new test to log in on Windows.
Allow role created by new test to log in on Windows. We must tell init about each role name we plan to connect as, else SSPI auth fails. Similar to previous patches such as 14793f471, 973542866. Oversight in 208927e65, per buildfarm member drongo. (Although that was back-patched to v13, the test script only exists in v16 and up.) Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/da44d71e799d5b3f03256169334044ad817c1dd7 Modified Files -- contrib/pg_prewarm/t/001_basic.pl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Allow role created by new test to log in on Windows.
Allow role created by new test to log in on Windows. We must tell init about each role name we plan to connect as, else SSPI auth fails. Similar to previous patches such as 14793f471, 973542866. Oversight in 208927e65, per buildfarm member drongo. (Although that was back-patched to v13, the test script only exists in v16 and up.) Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c26a8eaf650281ad08e9c5bdf39ec9387335a86c Modified Files -- contrib/pg_prewarm/t/001_basic.pl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Fix EvalPlanQual handling of foreign/custom joins in ExecScanFet
Fix EvalPlanQual handling of foreign/custom joins in ExecScanFetch. If inside an EPQ recheck, ExecScanFetch would run the recheck method function for foreign/custom joins even if they aren't descendant nodes in the EPQ recheck plan tree, which is problematic at least in the foreign-join case, because such a foreign join isn't guaranteed to have an alternative local-join plan required for running the recheck method function; in the postgres_fdw case this could lead to a segmentation fault or an assert failure in an assert-enabled build when running the recheck method function. Even if inside an EPQ recheck, any scan nodes that aren't descendant ones in the EPQ recheck plan tree should be normally processed by using the access method function; fix by modifying ExecScanFetch so that if inside an EPQ recheck, it runs the recheck method function for foreign/custom joins that are descendant nodes in the EPQ recheck plan tree as before and runs the access method function for foreign/custom joins that aren't. This fix also adds to postgres_fdw an isolation test for an EPQ recheck that caused issues stated above. Oversight in commit 385f337c9. Reported-by: Kristian Lejao Author: Masahiko Sawada Co-authored-by: Etsuro Fujita Reviewed-by: Michael Paquier Reviewed-by: Etsuro Fujita Discussion: https://postgr.es/m/CAD21AoBpo6Gx55FBOW+9s5X=nuw3xpq64v35fpdeksternc...@mail.gmail.com Backpatch-through: 13 Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2bb84ea7ef89961ab3c02c4496a44b6335fc79e9 Modified Files -- contrib/postgres_fdw/.gitignore | 2 + contrib/postgres_fdw/Makefile| 2 + contrib/postgres_fdw/expected/eval_plan_qual.out | 37 contrib/postgres_fdw/meson.build | 6 +++ contrib/postgres_fdw/specs/eval_plan_qual.spec | 55 src/backend/executor/execScan.c | 22 +++--- 6 files changed, 117 insertions(+), 7 deletions(-)
pgsql: Fix EvalPlanQual handling of foreign/custom joins in ExecScanFet
Fix EvalPlanQual handling of foreign/custom joins in ExecScanFetch. If inside an EPQ recheck, ExecScanFetch would run the recheck method function for foreign/custom joins even if they aren't descendant nodes in the EPQ recheck plan tree, which is problematic at least in the foreign-join case, because such a foreign join isn't guaranteed to have an alternative local-join plan required for running the recheck method function; in the postgres_fdw case this could lead to a segmentation fault or an assert failure in an assert-enabled build when running the recheck method function. Even if inside an EPQ recheck, any scan nodes that aren't descendant ones in the EPQ recheck plan tree should be normally processed by using the access method function; fix by modifying ExecScanFetch so that if inside an EPQ recheck, it runs the recheck method function for foreign/custom joins that are descendant nodes in the EPQ recheck plan tree as before and runs the access method function for foreign/custom joins that aren't. This fix also adds to postgres_fdw an isolation test for an EPQ recheck that caused issues stated above. Oversight in commit 385f337c9. Reported-by: Kristian Lejao Author: Masahiko Sawada Co-authored-by: Etsuro Fujita Reviewed-by: Michael Paquier Reviewed-by: Etsuro Fujita Discussion: https://postgr.es/m/CAD21AoBpo6Gx55FBOW+9s5X=nuw3xpq64v35fpdeksternc...@mail.gmail.com Backpatch-through: 13 Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b141443259845de6901be70e8eaa090a483ab68f Modified Files -- contrib/postgres_fdw/.gitignore | 2 + contrib/postgres_fdw/Makefile| 2 + contrib/postgres_fdw/expected/eval_plan_qual.out | 37 contrib/postgres_fdw/meson.build | 6 +++ contrib/postgres_fdw/specs/eval_plan_qual.spec | 55 src/include/executor/execScan.h | 22 +++--- 6 files changed, 117 insertions(+), 7 deletions(-)
pgsql: Fix update-po for the PGXS case
Fix update-po for the PGXS case The original formulation failed to take into account the fact that for the PGXS case, the source dir is not $(top_srcdir), so it ended up not doing anything. Handle it explicitly. Author: Ryo Matsumura Reviewed-by: Bryan Green Backpatch-through: 13 Discussion: https://postgr.es/m/tycpr01mb113164770fb0b0be6ed21e68ee8...@tycpr01mb11316.jpnprd01.prod.outlook.com Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a8933194e51585ed896c5c2b4a8e2ec5e3667a67 Modified Files -- src/nls-global.mk | 5 + 1 file changed, 5 insertions(+)
pgsql: Change reset_extra into a config_generic common field
Change reset_extra into a config_generic common field This is not specific to the GUC parameter type, so it can be part of the generic struct rather than the type-specific struct (like the related "extra" field). This allows for some code simplifications. Reviewed-by: Chao Li Discussion: https://www.postgresql.org/message-id/flat/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/5f4c3b33a97688174dfff44bdbc9ac228095714a Modified Files -- src/backend/utils/misc/guc.c | 115 +++-- src/include/utils/guc_tables.h | 6 +-- 2 files changed, 32 insertions(+), 89 deletions(-)
pgsql: Don't include execnodes.h in replication/conflict.h
Don't include execnodes.h in replication/conflict.h ... which silently propagates a lot of headers into many places via pgstat.h, as evidenced by the variety of headers that this patch needs to add to seemingly random places. Add a minimum of typedefs to conflict.h to be able to remove execnodes.h, and fix the fallout. Backpatch to 18, where conflict.h first appeared. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7e638d7f5093fd24837ebe709135fa16ef8e3e7b Modified Files -- src/backend/access/transam/multixact.c | 1 + src/backend/access/transam/xlogrecovery.c | 1 + src/backend/storage/ipc/waiteventset.c | 1 + src/backend/utils/activity/pgstat_backend.c | 1 + src/include/pgstat.h| 1 + src/include/replication/conflict.h | 9 - 6 files changed, 13 insertions(+), 1 deletion(-)
pgsql: Tidyup truncate_useless_pathkeys() function
Tidyup truncate_useless_pathkeys() function This removes a few static functions and replaces them with 2 functions which aim to be more reusable. The upper planner's pathkey requirements can be simplified down to operations which require pathkeys in the same order as the pathkeys for the given operation, and operations which can make use of a Path's pathkeys in any order. Here we also add some short-circuiting to truncate_useless_pathkeys(). At any point we discover that all pathkeys are useful to a single operation, we can stop checking the remaining operations as we're not going to be able to find any further useful pathkeys - they're all possibly useful already. Adjusting this seems to warrant trying to put the checks roughly in order of least-expensive-first so that the short-circuits have the most chance of skipping the more expensive checks. In passing clean up has_useful_pathkeys() as it seems to have grown a redundant check for group_pathkeys. This isn't needed as standard_qp_callback will set query_pathkeys if there's any requirement to have group_pathkeys. All this code does is waste run-time effort and take up needless space. Author: David Rowley Reviewed-by: Richard Guo Reviewed-by: Chao Li Discussion: https://postgr.es/m/caaphdvpbseotksvw5901mmozo-hhf78e5up3udofkjnxde_...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e3b9e44689051d5bee199e333c748aac83396378 Modified Files -- src/backend/optimizer/path/pathkeys.c | 213 +- 1 file changed, 82 insertions(+), 131 deletions(-)
pgsql: Fix issue with reading zero bytes in Gzip_read.
Fix issue with reading zero bytes in Gzip_read. pg_dump expects a read request of zero bytes to be a no-op; see for example ReadStr(). Gzip_read got this wrong and falsely supposed that the resulting gzret == 0 indicated an error. We could complicate that error-checking logic some more, but it seems best to just fall out immediately when passed size == 0. This bug breaks the nominally-supported case of manually gzip'ing the toc.dat file within a directory-style dump, so back-patch to v16 where this code came in. (Prior branches already have a short-circuit for size == 0 before their only gzread call.) Author: Tom Lane Reviewed-by: Chao Li Discussion: https://postgr.es/m/[email protected] Backpatch-through: 16 Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/6a4009747c3687bf1fdfef5f0b75c33681f37a10 Modified Files -- src/bin/pg_dump/compress_gzip.c | 4 1 file changed, 4 insertions(+)
pgsql: Fix two typos in xlogstats.h and xlogstats.c
Fix two typos in xlogstats.h and xlogstats.c Issue found while browsing this area of the code, introduced and copy-pasted around by 2258e76f90bf. Backpatch-through: 15 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5bc057d1f3afe6f6f0d902e3da89aa3770c79ceb Modified Files -- src/backend/access/transam/xlogstats.c | 2 +- src/include/access/xlogstats.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
Re: pgsql: doc: Remove trailing whitespace in xref
> On 22 Sep 2025, at 10:17, Daniel Gustafsson > wrote: > > doc: Remove trailing whitespace in xref > > Remove stray whitespace in xref tag. > > This was found due to a regression in xmllint 2.15.0 which flagged > this as an error, and at the time of this commit no fix for xmllint > has shipped. > > Author: Erik Wienhold > Discussion: https://postgr.es/m/[email protected] > Backpatch-through: 17 > > Branch > -- > REL_18_STABLE I am so sorry, I realized my mistake the second I hit enter, I meant to just stage it and accidentally instead did all branches =( Reverted immediately. I am going to go stand in the corner. -- Daniel Gustafsson
pgsql: Add test for pg_stat_reset_single_table_counters() on index
Add test for pg_stat_reset_single_table_counters() on index stats.sql is already doing some tests coverage on index statistics, by retrieving for example idx_scan and friends in pg_stat_all_tables. pg_stat_reset_single_table_counters() is supported for an index for a long time, but the case was never covered. This commit closes the gap, by using this reset function on an index, cross-checking the contents of pg_stat_all_indexes. Author: Bertrand Drouvot Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c173aaff98f898564998c0f5e4df9b6fca8a0f9c Modified Files -- src/test/regress/expected/stats.out | 21 + src/test/regress/sql/stats.sql | 9 + 2 files changed, 30 insertions(+)
pgsql: Consistently handle tab delimiters for wait event names
Consistently handle tab delimiters for wait event names Format validation and element extraction for intermediate line strings were inconsistent in their handling of tab delimiters, which resulted in an unclear error when multiple tab characters were used as a delimiter. This fixes it by using captures from the validation regex instead of a separate split() to avoid the inconsistency. Also, it ensures that \t+ is used consistently when inspecting the strings. Author: Kyotaro Horiguchi Reviewed-by: Daniel Gustafsson Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/711ccce38f222e992493d95f244e2b02744f Modified Files -- src/backend/utils/activity/generate-wait_event_types.pl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix two typos in xlogstats.h and xlogstats.c
Fix two typos in xlogstats.h and xlogstats.c Issue found while browsing this area of the code, introduced and copy-pasted around by 2258e76f90bf. Backpatch-through: 15 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/fa30f0cb06a184d13078832efc0052b9792de6f8 Modified Files -- src/backend/access/transam/xlogstats.c | 2 +- src/include/access/xlogstats.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix EvalPlanQual handling of foreign/custom joins in ExecScanFet
Fix EvalPlanQual handling of foreign/custom joins in ExecScanFetch. If inside an EPQ recheck, ExecScanFetch would run the recheck method function for foreign/custom joins even if they aren't descendant nodes in the EPQ recheck plan tree, which is problematic at least in the foreign-join case, because such a foreign join isn't guaranteed to have an alternative local-join plan required for running the recheck method function; in the postgres_fdw case this could lead to a segmentation fault or an assert failure in an assert-enabled build when running the recheck method function. Even if inside an EPQ recheck, any scan nodes that aren't descendant ones in the EPQ recheck plan tree should be normally processed by using the access method function; fix by modifying ExecScanFetch so that if inside an EPQ recheck, it runs the recheck method function for foreign/custom joins that are descendant nodes in the EPQ recheck plan tree as before and runs the access method function for foreign/custom joins that aren't. This fix also adds to postgres_fdw an isolation test for an EPQ recheck that caused issues stated above. Oversight in commit 385f337c9. Reported-by: Kristian Lejao Author: Masahiko Sawada Co-authored-by: Etsuro Fujita Reviewed-by: Michael Paquier Reviewed-by: Etsuro Fujita Discussion: https://postgr.es/m/CAD21AoBpo6Gx55FBOW+9s5X=nuw3xpq64v35fpdeksternc...@mail.gmail.com Backpatch-through: 13 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/12b0c0e51b2fed1f36816a0ea53a4f8e44455ec1 Modified Files -- contrib/postgres_fdw/.gitignore | 2 + contrib/postgres_fdw/Makefile| 2 + contrib/postgres_fdw/expected/eval_plan_qual.out | 37 contrib/postgres_fdw/specs/eval_plan_qual.spec | 55 src/backend/executor/execScan.c | 22 +++--- 5 files changed, 111 insertions(+), 7 deletions(-)
pgsql: Remove overzealous _bt_killitems assertion.
Remove overzealous _bt_killitems assertion. An assertion in _bt_killitems expected the scan's currPos state to contain a valid LSN, saved from when currPos's page was initially read. The assertion failed to account for the fact that even logged relations can have leaf pages with an invalid LSN when built with wal_level set to "minimal". Remove the faulty assertion. Oversight in commit e6eed40e (though note that the assertion was backpatched to stable branches before 18 by commit 7c319f54). Author: Peter Geoghegan Reported-By: Matthijs van der Vleuten Bug: #19082 Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13 Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/61de81a496dcd50187e8de765f4c3ed0267764ef Modified Files -- src/backend/access/nbtree/nbtutils.c | 1 - 1 file changed, 1 deletion(-)
pgsql: Fix lookups in pg_{clear,restore}_{attribute,relation}_stats().
Fix lookups in pg_{clear,restore}_{attribute,relation}_stats().
Presently, these functions look up the relation's OID, lock it, and
then check privileges. Not only does this approach provide no
guarantee that the locked relation matches the arguments of the
lookup, but it also allows users to briefly lock relations for
which they do not have privileges, which might enable
denial-of-service attacks. This commit adjusts these functions to
use RangeVarGetRelidExtended(), which is purpose-built to avoid
both of these issues. The new RangeVarGetRelidCallback function is
somewhat complicated because it must handle both tables and
indexes, and for indexes, we must check privileges on the parent
table and lock it first. Also, it needs to handle a couple of
extremely unlikely race conditions involving concurrent OID reuse.
A downside of this change is that the coding doesn't allow for
locking indexes in AccessShare mode anymore; everything is locked
in ShareUpdateExclusive mode. Per discussion, the original choice
of lock levels was intended for a now defunct implementation that
used in-place updates, so we believe this change is okay.
Reviewed-by: Jeff Davis
Discussion: https://postgr.es/m/Z8zwVmGzXyDdkAXj%40nathan
Backpatch-through: 18
Branch
--
REL_18_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/c8af5019bee5c57502db830f8005a01cba60fee0
Modified Files
--
src/backend/statistics/attribute_stats.c | 16 +--
src/backend/statistics/relation_stats.c| 8 +-
src/backend/statistics/stat_utils.c| 152 +++--
src/include/statistics/stat_utils.h| 8 +-
src/test/regress/expected/stats_import.out | 6 +-
5 files changed, 103 insertions(+), 87 deletions(-)
pgsql: Add pg_database_locale() to retrieve database default locale.
Add pg_database_locale() to retrieve database default locale. Reviewed-by: Peter Eisentraut Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e533524b23b8dd504d38c09c9f84b38289ca635d Modified Files -- src/backend/utils/adt/pg_locale.c | 9 + src/include/utils/pg_locale.h | 1 + 2 files changed, 10 insertions(+)
pgsql: Add pg_iswxdigit(), useful for tsearch.
Add pg_iswxdigit(), useful for tsearch. Reviewed-by: Peter Eisentraut Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/67a8b49e96caf0782b556521c8d6650e78f2d88e Modified Files -- src/backend/utils/adt/pg_locale.c | 12 src/backend/utils/adt/pg_locale_builtin.c | 7 +++ src/backend/utils/adt/pg_locale_icu.c | 7 +++ src/backend/utils/adt/pg_locale_libc.c| 23 +++ src/include/utils/pg_locale.h | 2 ++ 5 files changed, 51 insertions(+)
pgsql: Allow private state in certain planner data structures.
Allow private state in certain planner data structures. Extension that make extensive use of planner hooks may want to coordinate their efforts, for example to avoid duplicate computation, but that's currently difficult because there's no really good way to pass data between different hooks. To make that easier, allow for storage of extension-managed private state in PlannerGlobal, PlannerInfo, and RelOptInfo, along very similar lines to what we have permitted for ExplainState since commit c65bc2e1d14a2d4daed7c1921ac518f2c5ac3d17. Reviewed-by: Andrei Lepikhov Reviewed-by: Melanie Plageman Reviewed-by: Tom Lane Discussion: http://postgr.es/m/ca+tgmoywkhu2hkr62toyzh-ktdenmdelw7gkoonjl-tnouq...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0132dddab33a6eae2d3d63eda9f053e745fedb06 Modified Files -- src/backend/optimizer/util/Makefile | 1 + src/backend/optimizer/util/extendplan.c | 183 src/backend/optimizer/util/meson.build | 1 + src/include/nodes/pathnodes.h | 12 +++ src/include/optimizer/extendplan.h | 72 + 5 files changed, 269 insertions(+)
pgsql: Cleanup VACUUM option processing error messages
Cleanup VACUUM option processing error messages The processing of the PARALLEL option for VACUUM was not quite following what the DefElem code had intended. defGetInt32() already has code to handle missing parameters and returns a perfectly good error message for when that happens. Here we get rid of the ExecVacuum() error: ERROR: parallel option requires a value between 0 and N and leave defGetInt32() handle it, which will give: ERROR: parallel requires an integer value defGetInt32() was already handling the non-integer parameter case, so it may as well handle the missing parameter case too. Additionally, parameterize the option name to make translator work easier, and also use errhint_internal() rather than errhint() for the BUFFER_USAGE_LIMIT option since there isn't any work for a translator to do for "%s". Author: David Rowley Reviewed-by: Álvaro Herrera Reviewed-by: Masahiko Sawada Discussion: https://postgr.es/m/CAApHDvovH14tNWB+WvP6TSbfi7-=tysq9h5tq5agavwywrw...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/1b073cba4993b31fbf820504f297efce5d951c00 Modified Files -- src/backend/commands/vacuum.c| 42 ++-- src/test/regress/expected/vacuum.out | 6 ++ 2 files changed, 18 insertions(+), 30 deletions(-)
pgsql: Avoid warnings in tests when openssl binary isn't available
Avoid warnings in tests when openssl binary isn't available The SSL tests for pg_stat_ssl tries to exactly match the serial from the certificate by extracting it with the openssl binary. If that fails due to the binary not being available, a fallback match is used, but the attempt to execute a missing binary adds a warning to the output which can confuse readers for a failure in the test. Fix by only attempting if the openssl binary was found by autoconf/meson. Backpatch down to v16 where commit c8e4030d1bdd made the test use the OPENSSL variable from autoconf/meson instead of a hard- coded value. Author: Daniel Gustafsson Reported-by: Christoph Berg Discussion: https://postgr.es/m/[email protected] Backpatch-through: 16 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7d129ba54e7425baf43aa518d417ba3e4e94a443 Modified Files -- src/test/ssl/t/001_ssltests.pl | 42 +++--- 1 file changed, 19 insertions(+), 23 deletions(-)
pgsql: Doc: clarify n_distinct_inherited setting
Doc: clarify n_distinct_inherited setting There was some confusion around how to adjust the n_distinct estimates for partitioned tables. Here we try and clarify that n_distinct_inherited needs to be adjusted rather than n_distinct. Also fix some slightly misleading text which was talking about table size rather than table rows, fix a grammatical error, and adjust some text which indicated that ANALYZE was performing calculations based on the n_distinct settings. Really it's the query planner that does this and ANALYZE only stores the overridden n_distinct estimate value in pg_statistic. Author: David Rowley Reviewed-by: David G. Johnston Reviewed-by: Chao Li Backpatch-through: 13 Discussion: https://postgr.es/m/CAApHDvrL7a-ZytM1SP8Uk9nEw9bR2CPzVb+uP+bcNj=_q-z...@mail.gmail.com Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/46086fb6812ffdc15f5277574cc0b5cbc4d81b89 Modified Files -- doc/src/sgml/ref/alter_table.sgml | 34 -- 1 file changed, 16 insertions(+), 18 deletions(-)
pgsql: dblink: Avoid locking relation before privilege check.
dblink: Avoid locking relation before privilege check. The present coding of dblink's get_rel_from_relname() predates the introduction of RangeVarGetRelidExtended(), which provides a way to check permissions before locking the relation. This commit adjusts get_rel_from_relname() to use that function. Reviewed-by: Jeff Davis Discussion: https://postgr.es/m/aOgmi6avE6qMw_6t%40nathan Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c9b299f6df983ff3b196677a625393c31598d86f Modified Files -- contrib/dblink/dblink.c | 29 +++-- 1 file changed, 19 insertions(+), 10 deletions(-)
