pgsql: Add pg_iswalpha() and related functions.
Add pg_iswalpha() and related functions. Per-character pg_locale_t APIs. Useful for tsearch parsing and potentially other places. Significant overlap with the regc_wc_isalpha() and related functions in regc_pg_locale.c, but this change leaves those intact for now. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/af164f31b9f5f00561d5831a72ab91cfe091f92e Modified Files -- src/backend/regex/regc_pg_locale.c | 150 ++ src/backend/utils/adt/pg_locale.c | 124 src/include/utils/pg_locale.h | 12 +++ src/include/utils/pg_locale_c.h| 160 + 4 files changed, 302 insertions(+), 144 deletions(-)
pgsql: Fix lookup code for REINDEX INDEX.
Fix lookup code for REINDEX INDEX. This commit adjusts RangeVarCallbackForReindexIndex() to handle an extremely unlikely race condition involving concurrent OID reuse. In short, if REINDEX INDEX is executed at the same time that the index is re-created with the same name and OID but a different parent table OID, we might lock the wrong parent table. To fix, simply detect when this happens and emit an ERROR. Unfortunately, we can't gracefully handle this situation because we will have already locked the index, and we must lock the parent table before the index to avoid deadlocks. While at it, I've replaced all but one early return in this callback function with ERRORs that should be unreachable. While I haven't verified the presence of a live bug, the checks in question appear to be unnecessary, and the early returns seem prone to breaking the parent table locking code in subtle ways. If nothing else, this simplifies the code a bit. This is a bug fix and could be back-patched, but given the presumed rarity of the race condition and the lack of reports, I'm not going to bother. Reviewed-by: Tom Lane Reviewed-by: Jeff Davis Discussion: https://postgr.es/m/Z8zwVmGzXyDdkAXj%40nathan Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/079480dc20223dfe03d60fcabda9c0a65e30d0d5 Modified Files -- src/backend/commands/indexcmds.c | 50 1 file changed, 25 insertions(+), 25 deletions(-)
Re: pgsql: Move gramparse.h to src/backend/parser
John Naylor writes: > On Wed, Oct 15, 2025 at 2:49 PM Anton A. Melnikov > wrote: >> Maybe backpatch [2] to all supported versions not just 16+? > That only changed src/backend/common.mk, so that's not going to affect > contrib. I looked, and contrib/contrib-global.mk doesn't have any > extra *.bc file handling to begin with (as expected). Also, that fix > was in response to a specific change in dependencies, so I don't see > how it's directly applicable to earlier branches. Maybe there is > something to be done here, but with such a sporadic failure, I'm not > sure what. Yeah. One build failure in three years does not sound to me like something to panic about. It sounds more like a local problem. Also, I note that alligator is self-described as running a "gcc experimental (nightly build)" compiler, so temporary build glitches on it are hardly unexpected. It seems like there's an increasing number of buildfarm animals whose aims are less "test Postgres" than "test platform X by building Postgres on it". alligator is not the only experimental-tool-chain animal, and fruitcrow (GNU Hurd) is another example we've been seeing failures from lately. I don't want to tell those folk to go away, but maybe we should have some kind of annotation about "platform not believed stable" to remind us not to put huge amounts of effort into transient failures on those animals. regards, tom lane
pgsql: Fix reset of incorrect hash iterator in GROUPING SETS queries
Fix reset of incorrect hash iterator in GROUPING SETS queries This fixes an unlikely issue when fetching GROUPING SET results from their internally stored hash tables. It was possible in rare cases that the hash iterator would be set up incorrectly which could result in a crash. This was introduced in 4d143509c, so backpatch to v18. Many thanks to Yuri Zamyatin for reporting and helping to debug this issue. Bug: #19078 Reported-by: Yuri Zamyatin Author: David Rowley Reviewed-by: Jeff Davis Discussion: https://postgr.es/m/[email protected] Backpatch-through: 18 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/5c0a20003b4396930a354105ccf47402ca5047d2 Modified Files -- src/backend/executor/nodeAgg.c | 2 +- src/include/lib/simplehash.h | 4 2 files changed, 5 insertions(+), 1 deletion(-)
pgsql: bufmgr: fewer calls to BufferDescriptorGetContentLock
bufmgr: fewer calls to BufferDescriptorGetContentLock We're planning to merge buffer content locks into BufferDesc.state. To reduce the size of that patch, centralize calls to BufferDescriptorGetContentLock(). The biggest part of the change is in assertions, by introducing BufferIsLockedByMe[InMode]() (and removing BufferIsExclusiveLocked()). This seems like an improvement even without aforementioned plans. Additionally replace some direct calls to LWLockAcquire() with calls to LockBuffer(). Reviewed-by: Matthias van de Meent Discussion: https://postgr.es/m/fvfmkr5kk4nyex56ejgxj3uzi63isfxovp2biecb4bspbjrze7@az2pljabhnff Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/3baae90013df58a8d124afa79df07075b8ebea09 Modified Files -- src/backend/access/heap/visibilitymap.c | 3 +- src/backend/access/transam/xloginsert.c | 3 +- src/backend/storage/buffer/bufmgr.c | 70 ++--- src/include/storage/bufmgr.h| 3 +- 4 files changed, 61 insertions(+), 18 deletions(-)
pgsql: Improve ReadRecentBuffer() scalability
Improve ReadRecentBuffer() scalability While testing a new potential use for ReadRecentBuffer(), Andres reported that it scales badly when called concurrently for the same buffer by many backends. Instead of a naive (but wrong) coding with PinBuffer(), it used the spinlock, so that it could be careful to pin only if the buffer was valid and holding the expected block, to avoid breaking invariants in eg GetVictimBuffer(). Unfortunately that made it less scalable than PinBuffer(), which uses compare-exchange instead. We can fix that by giving PinBuffer() a new skip_if_not_valid mode that doesn't pin invalid buffers. It might occasionally skip when it shouldn't due to the unlocked read of the header flags, but that's unlikely and perfectly acceptable for an opportunistic optimisation routine, and it can only succeed when it really should due to the compare-exchange loop. Note that this fixes ReadRecentBuffer()'s failure to bump the usage count. While this could be seen as a bug, there currently aren't cases affected by this in core, so it doesn't seem worth backpatching that portion. Author: Thomas Munro Reported-by: Andres Freund Reviewed-by: Andres Freund Reviewed-by: Matthias van de Meent Discussion: https://postgr.es/m/20230627020546.t6z4tntmj7wmjrfh%40awork3.anarazel.de Discussion: https://postgr.es/m/fvfmkr5kk4nyex56ejgxj3uzi63isfxovp2biecb4bspbjrze7@az2pljabhnff Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/819dc118c0f6cd1fc08f0e807702b4bc0b0d8733 Modified Files -- src/backend/storage/buffer/bufmgr.c | 64 - 1 file changed, 28 insertions(+), 36 deletions(-)
pgsql: Fix incorrect message-printing in win32security.c.
Fix incorrect message-printing in win32security.c. log_error() would probably fail completely if used, and would certainly print garbage for anything that needed to be interpolated into the message, because it was failing to use the correct printing subroutine for a va_list argument. This bug likely went undetected because the error cases this code is used for are rarely exercised - they only occur when Windows security API calls fail catastrophically (out of memory, security subsystem corruption, etc). The FRONTEND variant can be fixed just by calling vfprintf() instead of fprintf(). However, there was no va_list variant of write_stderr(), so create one by refactoring that function. Following the usual naming convention for such things, call it vwrite_stderr(). Author: Bryan Green Reviewed-by: Tom Lane Discussion: https://postgr.es/m/CAF+pBj8goe4fRmZ0V3Cs6eyWzYLvK+HvFLYEYWG=tzam+tw...@mail.gmail.com Backpatch-through: 13 Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4c53519e15da6c055a9b63107ceb9fe6f6fb68b9 Modified Files -- src/backend/utils/error/elog.c | 16 +--- src/include/utils/elog.h | 1 + src/port/win32security.c | 4 ++-- 3 files changed, 16 insertions(+), 5 deletions(-)
pgsql: pgbench: Fix assertion failure with retriable errors in pipeline
pgbench: Fix assertion failure with retriable errors in pipeline mode. When running pgbench with --verbose-errors option and a custom script that triggered retriable errors (e.g., serialization errors) in pipeline mode, an assertion failure could occur: Assertion failed: (sql_script[st->use_file].commands[st->command]->type == 1), function commandError, file pgbench.c, line 3062. The failure happened because pgbench assumed these errors would only occur during SQL commands, but in pipeline mode they can also happen during \endpipeline meta command. This commit fixes the assertion failure by adjusting the assertion check to allow such errors during either SQL commands or \endpipeline. Backpatch to v15, where the assertion check was introduced. Author: Yugo Nagata Reviewed-by: Fujii Masao Discussion: https://postgr.es/m/CAHGQGwGWQMOzNkQs-LmpDHdNC0h8dmAuUMRvZrEntQi5a-b=k...@mail.gmail.com Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8b2e290bde21767373df9eef4b14bba282df8bdb Modified Files -- src/bin/pgbench/pgbench.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-)
pgsql: Fix redefinition of typedef RangeVar.
Fix redefinition of typedef RangeVar. Commit c8af5019be added a forward declaration for this typedef that caused redefinitions, which are not valid in C99. Per buildfarm members longfin and sifaka. Discussion: https://postgr.es/m/aO_fzfnKVXMd_RUM%40nathan Backpatch-through: 18 only Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/15d7dded0e930b5781b2c0e591c1b45eb078a248 Modified Files -- src/include/statistics/stat_utils.h | 4 ++-- 1 file 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_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5a9af48689dc4e67e1db305be9435866f158e9e0 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: plpython: Remove support for major version conflict detection
plpython: Remove support for major version conflict detection This essentially reverts commit 866566a690b, which installed safeguards against loading plpython2 and plpython3 into the same process. We don't support plpython2 anymore, so this is obsolete. The Python and PL/Python initialization now happens again in _PG_init() rather than the first time a PL/Python call handler is invoked. (Often, these will be very close together.) I kept the separate PLy_initialize() function introduced by 866566a690b to keep _PG_init() a bit modular. Reviewed-by: Mario González Troncoso Reviewed-by: Nathan Bossart Discussion: https://www.postgresql.org/message-id/flat/9eb9feb6-1df3-4f0c-a0dc-9bcf35273111%40eisentraut.org Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/594ba21bce05e8682eaf024f705fea8aeaba5ef3 Modified Files -- src/pl/plpython/plpy_main.c | 65 +++-- 1 file changed, 4 insertions(+), 61 deletions(-)
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_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/771b106d1994c494e341257aa4ed6e31dd9c2a45 Modified Files -- src/interfaces/libpq/fe-secure-gssapi.c | 27 +++ 1 file changed, 15 insertions(+), 12 deletions(-)
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_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a7346770813e31c3fd38616ebcc1beb61d551eea Modified Files -- src/bin/pg_combinebackup/pg_combinebackup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: pg_createsubscriber: Use new routine to retrieve data of PG_VERS
pg_createsubscriber: Use new routine to retrieve data of PG_VERSION pg_createsubscriber is documented as requiring the same major version as the target clusters. Attempting to use this tool on a cluster where the control file version read does not match with the version compiled with would lead to the following error message: pg_createsubscriber: error: control file appears to be corrupt This is confusing as the control file is correct: only the version expected does not match. This commit integrates pg_createsubscriber with the facility added by cd0be131ba6f, where the contents of PG_VERSION are read and compared with the value of PG_MAJORVERSION_NUM expected by the tool. This puts pg_createsubscriber in line with the documentation, with a better error message when the version does not match. Author: Michael Paquier Reviewed-by: Masahiko Sawada Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/fa55be2a506a2cab1d62430cc2217413f9ec Modified Files -- src/bin/pg_basebackup/pg_createsubscriber.c | 19 ++- 1 file changed, 14 insertions(+), 5 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_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a61592253e57b7e7034e9a6158f709343280bb43 Modified Files -- src/backend/replication/pgoutput/pgoutput.c | 27 --- 1 file changed, 16 insertions(+), 11 deletions(-)
pgsql: Generate EUC_CN mappings from gb18030-2022.ucm
Generate EUC_CN mappings from gb18030-2022.ucm In the wake of cfa6cd292, EUC_CN was the only encoding that used gb-18030-2000.xml to generate the .map files. Since EUC_CN is a subset of GB18030, we can easily use the same UCM file. This allows deleting the XML file from our repository. Author: Chao Li Discussion: https://postgr.es/m/CANWCAZaNRXZ-5NuXmsaMA2mKvMZnCGHZqQusLkpE%2B8YX%2Bi5OYg%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/48566180efff2f414ce806ca7705e811451b82ad Modified Files -- src/backend/utils/mb/Unicode/Makefile | 4 +- src/backend/utils/mb/Unicode/UCS_to_EUC_CN.pl |32 +- src/backend/utils/mb/Unicode/gb-18030-2000.xml | 30916 --- 3 files changed, 23 insertions(+), 30929 deletions(-)
pgsql: injection_points: Enable entry count in its variable-sized stats
injection_points: Enable entry count in its variable-sized stats This serves as coverage for the tracking of entry count added by 7bd2975fa92b as built-in variable-sized stats kinds have no need for it, at least not yet. A new function, called injection_points_stats_count(), is added to the module. It is able to return the number of entries. This has been useful when doing some benchmarking to check the sanity of the counts. Author: Michael Paquier Reviewed-by: Chao Li Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/acf0960c23090ea6690f2c5da3bc2625836516a9 Modified Files -- src/test/modules/injection_points/injection_points--1.0.sql | 10 ++ src/test/modules/injection_points/injection_stats.c | 12 src/test/modules/injection_points/t/001_stats.pl| 12 3 files changed, 34 insertions(+)
pgsql: Fix incorrect and inconsistent comments in tableam.h and heapam.
Fix incorrect and inconsistent comments in tableam.h and heapam.c. This commit corrects several issues in function comments: * The parameter "rel" was incorrectly referred to as "relation" in the comments for table_tuple_delete(), table_tuple_update(), and table_tuple_lock(). * In table_tuple_delete(), "changingPart" was listed as an output parameter in the comments but is actually input. * In table_tuple_update(), "slot" was listed as an input parameter in the comments but is actually output. * The comment for "update_indexes" in table_tuple_update() was mis-indented. * The comments for heap_lock_tuple() incorrectly referenced a non-existent "tid" parameter. Author: Chao Li Reviewed-by: Fujii Masao Discussion: https://postgr.es/m/CAEoWx2nB6Ay8g=ken7l3qbyx_4+slk9xomkv0xzqhr4cty8...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7fcb32ad023a434e07b7214c1c762ecd410b6969 Modified Files -- src/backend/access/heap/heapam.c | 1 - src/include/access/tableam.h | 16 +--- 2 files changed, 9 insertions(+), 8 deletions(-)
pgsql: test_bitmapset: Simplify code of the module
test_bitmapset: Simplify code of the module Two macros are added in this module, to cut duplicated patterns: - PG_ARG_GETBITMAPSET(), for input argument handling, with knowledge about NULL. - PG_RETURN_BITMAPSET_AS_TEXT(), that generates a text result from a Bitmapset. These changes limit the code so as the SQL functions are now mostly wrappers of the equivalent C function. Functions that use integer input arguments still need some NULL handling, like bms_make_singleton(). A NULL input is translated to "<>", which is what nodeToString() generates. Some of the tests are able to generate this result. Per discussion, the calls of bms_free() are removed. These may be justified if the functions are used in a rather long-lived memory context, but let's keep the code minimal for now. These calls used NULL checks, which were also not necessary as NULL is an input authorized by bms_free(). Some of the tests existed to cover behaviors related to the SQL functions for NULL inputs. Most of them are still relevant, as the routines of bitmapset.c are able to handle such cases. The coverage reports of bitmapset.c and test_bitmapset.c remain the same after these changes, with 300 lines of C code removed. Author: David Rowley Co-authored-by: Greg Burd Discussion: https://postgr.es/m/caaphdvqghmnm_zgsnefto9oaej0s-3cgb3gdsv7xvlc-hms...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/9952f6c05a40976063c3e2a4482873ec710f01a2 Modified Files -- .../test_bitmapset/expected/test_bitmapset.out | 271 +++-- .../modules/test_bitmapset/sql/test_bitmapset.sql | 84 +-- .../modules/test_bitmapset/test_bitmapset--1.0.sql | 2 +- src/test/modules/test_bitmapset/test_bitmapset.c | 615 + 4 files changed, 254 insertions(+), 718 deletions(-)
pgsql: Add planner_setup_hook and planner_shutdown_hook.
Add planner_setup_hook and planner_shutdown_hook. These hooks allow plugins to get control at the earliest point at which the PlannerGlobal object is fully initialized, and then just before it gets destroyed. This is useful in combination with the extendable plan state facilities (see extendplan.h) and perhaps for other purposes as well. 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/94f3ad3961a2cb32d30c79f01a70db4caff13318 Modified Files -- src/backend/optimizer/plan/planner.c | 14 ++ src/include/optimizer/planner.h | 13 + 2 files changed, 27 insertions(+)
pgsql: Remove block information from description of some WAL records fo
Remove block information from description of some WAL records for GIN The WAL records XLOG_GIN_INSERT and XLOG_GIN_VACUUM_DATA_LEAF_PAGE included some information about the blocks added to the record. This information is already provided by XLogRecGetBlockRefInfo() with much more details about the blocks included in each record, like the compression information, for example. This commit removes the block information that existed in the record descriptions specific to GIN. 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/7072a8855e84287f63ee4155124455145d70534c Modified Files -- src/backend/access/rmgrdesc/gindesc.c | 18 ++ 1 file changed, 2 insertions(+), 16 deletions(-)
pgsql: test_bitmapset: Expand more the test coverage
test_bitmapset: Expand more the test coverage This commit expands the set of tests added by 00c3d87a5cab, to bring the coverage of bitmapset.c close to 100% by addressing a lot of corner cases (most of these relate to word counts and reallocations). Some of the functions of this module also have their own idea of the result to return depending on the input values given. These are specific to the module, still let's add more coverage for all of them. Some comments are made more consistent in the tests, while on it. Author: Greg Burd Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/5668fff3c512a61b7f8a2b9bf04270578cf5665a Modified Files -- .../test_bitmapset/expected/test_bitmapset.out | 1072 +--- .../modules/test_bitmapset/sql/test_bitmapset.sql | 189 +++- .../modules/test_bitmapset/test_bitmapset--1.0.sql |4 + src/test/modules/test_bitmapset/test_bitmapset.c | 55 +- 4 files changed, 1157 insertions(+), 163 deletions(-)
pgsql: Fix privilege checks for pg_prewarm() on indexes.
Fix privilege checks for pg_prewarm() on indexes. pg_prewarm() currently checks for SELECT privileges on the target relation. However, indexes do not have access rights of their own, so a role may be denied permission to prewarm an index despite having the SELECT privilege on its parent table. This commit fixes this by locking the parent table before the index (to avoid deadlocks) and checking for SELECT on the parent table. Note that the code is largely borrowed from amcheck_lock_relation_and_check(). An obvious downside of this change is the extra AccessShareLock on the parent table during prewarming, but that isn't expected to cause too much trouble in practice. Author: Ayush Vatsa Co-authored-by: Nathan Bossart Reviewed-by: Tom Lane Reviewed-by: Jeff Davis Discussion: https://postgr.es/m/CACX%2BKaMz2ZoOojh0nQ6QNBYx8Ak1Dkoko%3DD4FSb80BYW%2Bo8CHQ%40mail.gmail.com Backpatch-through: 13 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/6c03ae8d6e810b7273c8d3828e864a79d13a37d5 Modified Files -- contrib/pg_prewarm/pg_prewarm.c | 47 ++--- 1 file changed, 44 insertions(+), 3 deletions(-)
pgsql: Don't include execnodes.h in brin.h or gin.h
Don't include execnodes.h in brin.h or gin.h These headers don't need execnodes.h for anything. I think they never have. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/1b6f61bd89889f704656005e7c1f1a40255230e5 Modified Files -- src/backend/access/brin/brin_bloom.c | 1 + src/include/access/brin.h| 3 ++- src/include/access/gin.h | 4 ++-- src/include/access/gin_private.h | 1 + 4 files changed, 6 insertions(+), 3 deletions(-)
pgsql: pg_createsubscriber: Fix matching check in TAP test
pg_createsubscriber: Fix matching check in TAP test 040_pg_createsubscriber has been calling safe_psql(), that returns the result of a SQL query, with ok() without checking the result generated (in this case 't', for a number of publications). The outcome of the tests is currently not impacted by this change. However, it could be possible that the test fails to detect future issues if the query results become different. The test is rewritten so as the number of publications is checked. This is not the fix suggested originally by the author, but this is more reliable in the long run. Oversight in e5aeed4b8020. Author: Sadhuprasad Patro Discussion: https://postgr.es/m/caff0-chhwnx_cv2uy7tkjodubeogprjpw4rpf1jqb16_1bu...@mail.gmail.com Backpatch-through: 18 Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/39e22b3adaa7738da4d7ff536a2ab5e303e7c890 Modified Files -- src/bin/pg_basebackup/t/040_pg_createsubscriber.pl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Replace defunct URL with stable archive.org URL in rbtree.c
Replace defunct URL with stable archive.org URL in rbtree.c The URL for "Sorting and Searching Algorithms: A Cookbook" by Thomas Niemann has started returning 404, and since we refer to the page for license terms this replaces the now defunct link with one to the copy on archive.org. Author: Chao Li Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6aa184c80f0cb0e20572441e0189567ed5176e1d Modified Files -- src/backend/lib/rbtree.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: Remove duplicated log related to slot creation in pg_createsubsc
Remove duplicated log related to slot creation in pg_createsubscriber The creation of a replication slot done in a specific database on a publisher was logged twice, with the second log not mentioning the database where the slot creation happened. This commit removes the information logged after a slot has been successfully created, moving the information about the publisher from the second to the first log. Note that failing a slot creation is also logged, so there is no loss of information. Author: Peter Smith Reviewed-by: Chao Li Discussion: https://postgr.es/m/CAHut+Pv7qDvLbDgc9PQGhULT3rPXTxdu_=w+iw-kms+zpad...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8d02f49696d81b1641412c2f4545403de37faadc Modified Files -- src/bin/pg_basebackup/pg_createsubscriber.c | 7 ++- 1 file changed, 2 insertions(+), 5 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 -- master Details --- https://git.postgresql.org/pg/commitdiff/b46efe90482bc1105a17955fce02cb3708230f0e Modified Files -- src/backend/replication/pgoutput/pgoutput.c | 29 - 1 file changed, 24 insertions(+), 5 deletions(-)
pgsql: Remove partColsUpdated.
Remove partColsUpdated. This information appears to have been unused since commit c5b7ba4e67. We could not find any references in third-party code, either. Reviewed-by: Chao Li Reviewed-by: Tom Lane Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/aO_CyFRpbVMtgJWM%40nathan Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/812221b204276b884d2b14ef56aabd9e1946be81 Modified Files -- src/backend/optimizer/plan/createplan.c | 4 src/backend/optimizer/plan/planner.c| 2 -- src/backend/optimizer/util/inherit.c| 10 -- src/backend/optimizer/util/pathnode.c | 4 src/include/nodes/pathnodes.h | 4 src/include/nodes/plannodes.h | 2 -- src/include/optimizer/pathnode.h| 1 - 7 files changed, 27 deletions(-)
pgsql: Fix internal error from CollateExpr in SQL/JSON DEFAULT expressi
Fix internal error from CollateExpr in SQL/JSON DEFAULT expressions
SQL/JSON functions such as JSON_VALUE could fail with "unrecognized
node type" errors when a DEFAULT clause contained an explicit COLLATE
expression. That happened because assign_collations_walker() could
invoke exprSetCollation() on a JsonBehavior expression whose DEFAULT
still contained a CollateExpr, which exprSetCollation() does not
handle.
For example:
SELECT JSON_VALUE('{"a":1}', '$.c' RETURNING text
DEFAULT 'A' COLLATE "C" ON EMPTY);
Fix by validating in transformJsonBehavior() that the DEFAULT
expression's collation matches the enclosing JSON expression’s
collation. In exprSetCollation(), replace the recursive call on the
JsonBehavior expression with an assertion that its collation already
matches the target, since the parser now enforces that condition.
Reported-by: Jian He
Author: Jian He
Reviewed-by: Amit Langote
Discussion:
https://postgr.es/m/cacjufxhvwyysyivq6o+psrx6zq7rafinh_fv1kcftst1xg4...@mail.gmail.com
Backpatch-through: 17
Branch
--
REL_17_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/09f86a42f25cd32d8d268484252671341033b2c0
Modified Files
--
src/backend/nodes/nodeFuncs.c | 8 +---
src/backend/parser/parse_expr.c| 57 ++
src/test/regress/expected/collate.icu.utf8.out | 49 ++
src/test/regress/sql/collate.icu.utf8.sql | 15 ++-
4 files changed, 114 insertions(+), 15 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_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4a08603a232265b2ecd0595e80a15af3e92b04c8 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: pg_createsubscriber: Add log message when no publications exist
pg_createsubscriber: Add log message when no publications exist to drop. When specifying --clean=publication to pg_createsubscriber, it drops all existing publications with a log message "dropping all existing publications in database "testdb"". Add a new log message "no publications found" when there are no publications to drop, making the progress more transparent to users. Author: Peter Smith Reviewed-by: Masahiko Sawada Discussion: https://postgr.es/m/CAHut+Ptm+WJwbbYXhC0s6FP_98KzZCR=5cpu8f8n5uv8p7b...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/74ac377d75135e02064fc4427bec401277b4f60c Modified Files -- src/bin/pg_basebackup/pg_createsubscriber.c | 13 + 1 file changed, 9 insertions(+), 4 deletions(-)
pgsql: Fix incorrect message-printing in win32security.c.
Fix incorrect message-printing in win32security.c. log_error() would probably fail completely if used, and would certainly print garbage for anything that needed to be interpolated into the message, because it was failing to use the correct printing subroutine for a va_list argument. This bug likely went undetected because the error cases this code is used for are rarely exercised - they only occur when Windows security API calls fail catastrophically (out of memory, security subsystem corruption, etc). The FRONTEND variant can be fixed just by calling vfprintf() instead of fprintf(). However, there was no va_list variant of write_stderr(), so create one by refactoring that function. Following the usual naming convention for such things, call it vwrite_stderr(). Author: Bryan Green Reviewed-by: Tom Lane Discussion: https://postgr.es/m/CAF+pBj8goe4fRmZ0V3Cs6eyWzYLvK+HvFLYEYWG=tzam+tw...@mail.gmail.com Backpatch-through: 13 Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b48ae226e6c31f5e1801e626d7602be7969f0fbd Modified Files -- src/backend/utils/error/elog.c | 16 +--- src/include/utils/elog.h | 1 + src/port/win32security.c | 4 ++-- 3 files changed, 16 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_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ca0c9390865dbd5a7324cf390f696ade33494974 Modified Files -- src/backend/access/nbtree/nbtutils.c | 1 - 1 file changed, 1 deletion(-)
pgsql: Fix reset of incorrect hash iterator in GROUPING SETS queries
Fix reset of incorrect hash iterator in GROUPING SETS queries This fixes an unlikely issue when fetching GROUPING SET results from their internally stored hash tables. It was possible in rare cases that the hash iterator would be set up incorrectly which could result in a crash. This was introduced in 4d143509c, so backpatch to v18. Many thanks to Yuri Zamyatin for reporting and helping to debug this issue. Bug: #19078 Reported-by: Yuri Zamyatin Author: David Rowley Reviewed-by: Jeff Davis Discussion: https://postgr.es/m/[email protected] Backpatch-through: 18 Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0b6a02f0355c8950ffe22b52eac86f6261e19caf Modified Files -- src/backend/executor/nodeAgg.c | 2 +- src/include/lib/simplehash.h | 4 2 files changed, 5 insertions(+), 1 deletion(-)
pgsql: Improve TAP tests by replacing ok() with better Test::More funct
Improve TAP tests by replacing ok() with better Test::More functions Transpose the changes made by commit fabb33b35 in 002_pg_dump.pl into its recently-created clone 006_pg_dump_compress.pl. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a6113dc1dae009a3d9a634d2fcc59d72d1dd7d7b Modified Files -- src/bin/pg_dump/t/006_pg_dump_compress.pl | 6 -- 1 file changed, 4 insertions(+), 2 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_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9a6ea00ac8c09fc73a8f725517ad7aea7664b1bc Modified Files -- src/backend/replication/slot.c | 7 +++ 1 file changed, 7 insertions(+)
pgsql: Fix StatisticsObjIsVisibleExt() for pg_temp.
Fix StatisticsObjIsVisibleExt() for pg_temp. Neighbor get_statistics_object_oid() ignores objects in pg_temp, as has been the standard for non-relation, non-type namespace searches since CVE-2007-2138. Hence, most operations that name a statistics object correctly decline to map an unqualified name to a statistics object in pg_temp. StatisticsObjIsVisibleExt() did not. Consequently, pg_statistics_obj_is_visible() wrongly returned true for such objects, psql \dX wrongly listed them, and getObjectDescription()-based ereport() and pg_describe_object() wrongly omitted namespace qualification. Any malfunction beyond that would depend on how a human or application acts on those wrong indications. Commit d99d58cdc8c0b5b50ee92995e8575c100b1a458a introduced this. Back-patch to v13 (all supported versions). Reviewed-by: Nathan Bossart Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13 Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d024160fffc8065b9b007c6be1b5f907eb2122c9 Modified Files -- src/backend/catalog/namespace.c | 3 +++ src/test/regress/expected/stats_ext.out | 14 ++ src/test/regress/sql/stats_ext.sql | 8 3 files changed, 25 insertions(+)
pgsql: Avoid uninitialized-variable warnings from older compilers.
Avoid uninitialized-variable warnings from older compilers. Some of the buildfarm is still unhappy with WinGetFuncArgInPartition even after 2273fa32b. While it seems to be just very old compilers, we can suppress the warnings and arguably make the code more readable by not initializing these variables till closer to where they are used. While at it, make a couple of cosmetic comment improvements. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/71540dcdcb2239d9398c586615761d5ea424aaf0 Modified Files -- src/backend/executor/nodeWindowAgg.c | 34 -- 1 file changed, 16 insertions(+), 18 deletions(-)
pgsql: Fix privilege checks for pg_prewarm() on indexes.
Fix privilege checks for pg_prewarm() on indexes. pg_prewarm() currently checks for SELECT privileges on the target relation. However, indexes do not have access rights of their own, so a role may be denied permission to prewarm an index despite having the SELECT privilege on its parent table. This commit fixes this by locking the parent table before the index (to avoid deadlocks) and checking for SELECT on the parent table. Note that the code is largely borrowed from amcheck_lock_relation_and_check(). An obvious downside of this change is the extra AccessShareLock on the parent table during prewarming, but that isn't expected to cause too much trouble in practice. Author: Ayush Vatsa Co-authored-by: Nathan Bossart Reviewed-by: Tom Lane Reviewed-by: Jeff Davis Discussion: https://postgr.es/m/CACX%2BKaMz2ZoOojh0nQ6QNBYx8Ak1Dkoko%3DD4FSb80BYW%2Bo8CHQ%40mail.gmail.com Backpatch-through: 13 Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/3ccf8e9ac96e87c9ec4693d437f3c5531eafa1b6 Modified Files -- contrib/pg_prewarm/pg_prewarm.c | 47 --- contrib/pg_prewarm/t/001_basic.pl | 29 +++- 2 files changed, 72 insertions(+), 4 deletions(-)
pgsql: Fix privilege checks for pg_prewarm() on indexes.
Fix privilege checks for pg_prewarm() on indexes. pg_prewarm() currently checks for SELECT privileges on the target relation. However, indexes do not have access rights of their own, so a role may be denied permission to prewarm an index despite having the SELECT privilege on its parent table. This commit fixes this by locking the parent table before the index (to avoid deadlocks) and checking for SELECT on the parent table. Note that the code is largely borrowed from amcheck_lock_relation_and_check(). An obvious downside of this change is the extra AccessShareLock on the parent table during prewarming, but that isn't expected to cause too much trouble in practice. Author: Ayush Vatsa Co-authored-by: Nathan Bossart Reviewed-by: Tom Lane Reviewed-by: Jeff Davis Discussion: https://postgr.es/m/CACX%2BKaMz2ZoOojh0nQ6QNBYx8Ak1Dkoko%3DD4FSb80BYW%2Bo8CHQ%40mail.gmail.com Backpatch-through: 13 Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a0551bc5734b16029bdbed3e7222fa6a1eb1625c Modified Files -- contrib/pg_prewarm/pg_prewarm.c | 47 --- contrib/pg_prewarm/t/001_basic.pl | 29 +++- 2 files changed, 72 insertions(+), 4 deletions(-)
pgsql: Fix privilege checks for pg_prewarm() on indexes.
Fix privilege checks for pg_prewarm() on indexes. pg_prewarm() currently checks for SELECT privileges on the target relation. However, indexes do not have access rights of their own, so a role may be denied permission to prewarm an index despite having the SELECT privilege on its parent table. This commit fixes this by locking the parent table before the index (to avoid deadlocks) and checking for SELECT on the parent table. Note that the code is largely borrowed from amcheck_lock_relation_and_check(). An obvious downside of this change is the extra AccessShareLock on the parent table during prewarming, but that isn't expected to cause too much trouble in practice. Author: Ayush Vatsa Co-authored-by: Nathan Bossart Reviewed-by: Tom Lane Reviewed-by: Jeff Davis Discussion: https://postgr.es/m/CACX%2BKaMz2ZoOojh0nQ6QNBYx8Ak1Dkoko%3DD4FSb80BYW%2Bo8CHQ%40mail.gmail.com Backpatch-through: 13 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/208927e656929df4ecc1efe8443dbcdbbcb23e38 Modified Files -- contrib/pg_prewarm/pg_prewarm.c | 47 --- contrib/pg_prewarm/t/001_basic.pl | 29 +++- 2 files changed, 72 insertions(+), 4 deletions(-)
pgsql: Fix privilege checks for pg_prewarm() on indexes.
Fix privilege checks for pg_prewarm() on indexes. pg_prewarm() currently checks for SELECT privileges on the target relation. However, indexes do not have access rights of their own, so a role may be denied permission to prewarm an index despite having the SELECT privilege on its parent table. This commit fixes this by locking the parent table before the index (to avoid deadlocks) and checking for SELECT on the parent table. Note that the code is largely borrowed from amcheck_lock_relation_and_check(). An obvious downside of this change is the extra AccessShareLock on the parent table during prewarming, but that isn't expected to cause too much trouble in practice. Author: Ayush Vatsa Co-authored-by: Nathan Bossart Reviewed-by: Tom Lane Reviewed-by: Jeff Davis Discussion: https://postgr.es/m/CACX%2BKaMz2ZoOojh0nQ6QNBYx8Ak1Dkoko%3DD4FSb80BYW%2Bo8CHQ%40mail.gmail.com Backpatch-through: 13 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/fae0ce5e318eea8cd8f7bac936a58ee7cbd10bf8 Modified Files -- contrib/pg_prewarm/pg_prewarm.c | 47 --- contrib/pg_prewarm/t/001_basic.pl | 29 +++- 2 files changed, 72 insertions(+), 4 deletions(-)
pgsql: Fix privilege checks for pg_prewarm() on indexes.
Fix privilege checks for pg_prewarm() on indexes. pg_prewarm() currently checks for SELECT privileges on the target relation. However, indexes do not have access rights of their own, so a role may be denied permission to prewarm an index despite having the SELECT privilege on its parent table. This commit fixes this by locking the parent table before the index (to avoid deadlocks) and checking for SELECT on the parent table. Note that the code is largely borrowed from amcheck_lock_relation_and_check(). An obvious downside of this change is the extra AccessShareLock on the parent table during prewarming, but that isn't expected to cause too much trouble in practice. Author: Ayush Vatsa Co-authored-by: Nathan Bossart Reviewed-by: Tom Lane Reviewed-by: Jeff Davis Discussion: https://postgr.es/m/CACX%2BKaMz2ZoOojh0nQ6QNBYx8Ak1Dkoko%3DD4FSb80BYW%2Bo8CHQ%40mail.gmail.com Backpatch-through: 13 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/19a64f5676bb51a3c01891c4bdb184ae48944936 Modified Files -- contrib/pg_prewarm/pg_prewarm.c | 47 ++--- 1 file changed, 44 insertions(+), 3 deletions(-)
pgsql: Bump XLOG_PAGE_MAGIC after xl_heap_prune change
Bump XLOG_PAGE_MAGIC after xl_heap_prune change add323da40a6 altered xl_heap_prune, changing the WAL format, but neglected to bump XLOG_PAGE_MAGIC. Do so now. Author: Melanie Plageman Reported-by: Kirill Reshke Reported-by: Michael Paquier Discussion: https://postgr.es/m/aO3Gw6hCAZFUd5ab%40paquier.xyz Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/4a8fb58671d36b8f6cb4f5c582b8dc5fa4d26702 Modified Files -- src/include/access/xlog_internal.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
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_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/fc287cf3c4c98cef16297e89e5946a7c66ffa33e Modified Files -- src/interfaces/libpq/fe-secure-gssapi.c | 27 +++ 1 file changed, 15 insertions(+), 12 deletions(-)
pgsql: Remove unused data_bufsz from DecodedBkpBlock struct.
Remove unused data_bufsz from DecodedBkpBlock struct. Author: Mikhail Gribkov Reviewed-by: Nazir Bilal Yavuz Discussion: https://postgr.es/m/CAMEv5_sxuaiAfSy1ZyN%3D7UGbHg3C10cwHhEk8nXEjiCsBVs4vQ%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/fd530650137e41bd2c3ed2b62724d5b47721a922 Modified Files -- src/include/access/xlogreader.h | 1 - 1 file changed, 1 deletion(-)
pgsql: Improve description of some WAL records for GIN
Improve description of some WAL records for GIN The following information is added in the description of some GIN records: - In INSERT_LISTPAGE, the number of tuples and the right link block. - In UPDATE_META_PAGE, the number of tuples, the previous tail block, and the right link block. - In SPLIT, the left and right children blocks. Author: Kirill Reshke Reviewed-by: Michael Paquier Reviewed-by: Andrey Borodin Discussion: https://postgr.es/m/CALdSSPgnAt5L=d_xgxrxlyo5fk1h31_eyeesxdu1n-r4g+6...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/138da727a174219da2d408382e50f8628f1fa38f Modified Files -- src/backend/access/rmgrdesc/gindesc.c | 24 ++-- 1 file changed, 22 insertions(+), 2 deletions(-)
pgsql: bufmgr: Fix valgrind checking for buffers pinned in StrategyGetB
bufmgr: Fix valgrind checking for buffers pinned in StrategyGetBuffer() In 5e899859287 I made StrategyGetBuffer() pin buffers with a single CAS, instead of using PinBuffer_Locked(). Unfortunately I missed that PinBuffer_Locked() marked the page as defined for valgrind. Fix this oversight by centralizing the valgrind initialization into TrackNewBufferPin(), which also allows us to reduce the number of places doing VALGRIND_MAKE_MEM_DEFINED. Per buildfarm animal skink and Amit Langote. Discussion: https://postgr.es/m/fvfmkr5kk4nyex56ejgxj3uzi63isfxovp2biecb4bspbjrze7@az2pljabhnff Discussion: https://postgr.es/m/ca+hiwqgkj6nexepqw7epykvsetzxp5-up_xhtcuakwftatv...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c819d1017ddb349d92ab323d2631bc1f10bb4e86 Modified Files -- src/backend/storage/buffer/bufmgr.c | 32 1 file changed, 16 insertions(+), 16 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_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f768f5a7d408c7a5efe45d49136818f7d4d0a62a Modified Files -- src/nls-global.mk | 5 + 1 file changed, 5 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_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/56cd332f80b260ebc1eef825d4b5acd6d6a54310 Modified Files -- src/nls-global.mk | 5 + 1 file changed, 5 insertions(+)
pgsql: Fix hashjoin memory balancing logic
Fix hashjoin memory balancing logic Commit a1b4f289beec improved the hashjoin sizing to also consider the memory used by BufFiles for batches. The code however had multiple issues, making it ineffective or not working as expected in some cases. * The amount of memory needed by buffers was calculated using uint32, so it would overflow for nbatch >= 262144. If this happened the loop would exit prematurely and the memory usage would not be reduced. The nbatch overflow is fixed by reworking the condition to not use a multiplication at all, so there's no risk of overflow. An explicit cast was added to a similar calculation in ExecHashIncreaseBatchSize. * The loop adjusting the nbatch value used hash_table_bytes to calculate the old/new size, but then updated only space_allowed. The consequence is the total memory usage was not reduced, but all the memory saved by reducing the number of batches was used for the internal hash table. This was fixed by using only space_allowed. This is also more correct, because hash_table_bytes does not account for skew buckets. * The code was also doubling multiple parameters (e.g. the number of buckets for hash table), but was missing overflow protections. The loop now checks for overflow, and terminates if needed. It'd be possible to cap the value and continue the loop, but it's not worth the complexity. And the overflow implies the in-memory hash table is already very large anyway. While at it, rework the comment explaining how the memory balancing works, to make it more concise and easier to understand. The initial nbatch overflow issue was reported by Vaibhav Jain. The other issues were noticed by me and Melanie Plageman. Fix by me, with a lot of review and feedback by Melanie. Backpatch to 18, where the hashjoin memory balancing was introduced. Reported-by: Vaibhav Jain Reviewed-by: Melanie Plageman Backpatch-through: 18 Discussion: https://postgr.es/m/caba-az174yvffq7rls+vnkaqyg7ina2exvpwmpwqnen6dit...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b85c4700fc5124999e22ea7300ecc0a290c81cbc Modified Files -- src/backend/executor/nodeHash.c | 122 +--- 1 file changed, 64 insertions(+), 58 deletions(-)
pgsql: Fix hashjoin memory balancing logic
Fix hashjoin memory balancing logic Commit a1b4f289beec improved the hashjoin sizing to also consider the memory used by BufFiles for batches. The code however had multiple issues, making it ineffective or not working as expected in some cases. * The amount of memory needed by buffers was calculated using uint32, so it would overflow for nbatch >= 262144. If this happened the loop would exit prematurely and the memory usage would not be reduced. The nbatch overflow is fixed by reworking the condition to not use a multiplication at all, so there's no risk of overflow. An explicit cast was added to a similar calculation in ExecHashIncreaseBatchSize. * The loop adjusting the nbatch value used hash_table_bytes to calculate the old/new size, but then updated only space_allowed. The consequence is the total memory usage was not reduced, but all the memory saved by reducing the number of batches was used for the internal hash table. This was fixed by using only space_allowed. This is also more correct, because hash_table_bytes does not account for skew buckets. * The code was also doubling multiple parameters (e.g. the number of buckets for hash table), but was missing overflow protections. The loop now checks for overflow, and terminates if needed. It'd be possible to cap the value and continue the loop, but it's not worth the complexity. And the overflow implies the in-memory hash table is already very large anyway. While at it, rework the comment explaining how the memory balancing works, to make it more concise and easier to understand. The initial nbatch overflow issue was reported by Vaibhav Jain. The other issues were noticed by me and Melanie Plageman. Fix by me, with a lot of review and feedback by Melanie. Backpatch to 18, where the hashjoin memory balancing was introduced. Reported-by: Vaibhav Jain Reviewed-by: Melanie Plageman Backpatch-through: 18 Discussion: https://postgr.es/m/caba-az174yvffq7rls+vnkaqyg7ina2exvpwmpwqnen6dit...@mail.gmail.com Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/aa151022ec13f6a24f70c30dbfb9a5747db620e8 Modified Files -- src/backend/executor/nodeHash.c | 122 +--- 1 file changed, 64 insertions(+), 58 deletions(-)
pgsql: Add more TAP test coverage for pg_dump.
Add more TAP test coverage for pg_dump. Add a test case to cover pg_dump with --compress=none. This brings the coverage of compress_none.c up from about 64% to 90%, in particular covering the new code added in a previous patch. Include compression of toc.dat in manually-compressed test cases. We would have found the bug fixed in commit a239c4a0c much sooner if we'd done this. As far as I can tell, this doesn't reduce test coverage at all, since there are other tests of directory format that still use an uncompressed toc.dat. Widen the wide row used to verify correct (de) compression. Commit 1a05c1d25 advises us (not without reason) to ensure that this test case fully fills DEFAULT_IO_BUFFER_SIZE, so that loops within the compression logic will iterate completely. To follow that advice with the proposed DEFAULT_IO_BUFFER_SIZE of 128K, we need something close to this. This does indeed increase the reported code coverage by a few lines. While here, fix a glitch that I noticed in testing: the $glob_patterns tests were incapable of failing, because glob() will return 'foo' as 'foo' whether there is a matching file or not. (Indeed, the stanza just above that one relies on that.) In my testing, this patch adds approximately as much runtime as was saved by the previous patch, so that it's about a wash compared to the old code. However, we get better test coverage. Author: Tom Lane Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/20ec9958921af9698e88d6f006c49a4d9d28f210 Modified Files -- src/bin/pg_dump/t/002_pg_dump.pl | 8 +++- src/bin/pg_dump/t/006_pg_dump_compress.pl | 66 +-- 2 files changed, 52 insertions(+), 22 deletions(-)
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_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/46c4478db421764c5785ddce4f07b34550316ec0 Modified Files -- src/interfaces/libpq/fe-secure-gssapi.c | 27 +++ 1 file changed, 15 insertions(+), 12 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_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f428b1231ccf39eded9db86acb72c87ad8aa0a8f Modified Files -- doc/src/sgml/ref/alter_table.sgml | 34 -- 1 file changed, 16 insertions(+), 18 deletions(-)
pgsql: pg_createsubscriber: Fix matching check in TAP test
pg_createsubscriber: Fix matching check in TAP test 040_pg_createsubscriber has been calling safe_psql(), that returns the result of a SQL query, with ok() without checking the result generated (in this case 't', for a number of publications). The outcome of the tests is currently not impacted by this change. However, it could be possible that the test fails to detect future issues if the query results become different. The test is rewritten so as the number of publications is checked. This is not the fix suggested originally by the author, but this is more reliable in the long run. Oversight in e5aeed4b8020. Author: Sadhuprasad Patro Discussion: https://postgr.es/m/caff0-chhwnx_cv2uy7tkjodubeogprjpw4rpf1jqb16_1bu...@mail.gmail.com Backpatch-through: 18 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d372888ade9e7f4796882d3e15b0d78ae329d0cb Modified Files -- src/bin/pg_basebackup/t/040_pg_createsubscriber.pl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
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 -- master Details --- https://git.postgresql.org/pg/commitdiff/ea78bd6d5d0f18c09db1e3ec6fd19be38d706030 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_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/bf5b26525b28a2abf8eef368921c12fdeaddc0d8 Modified Files -- src/test/ssl/t/001_ssltests.pl | 40 +++- 1 file changed, 19 insertions(+), 21 deletions(-)
pgsql: Make some use of anonymous unions [DSM registry].
Make some use of anonymous unions [DSM registry]. Make some use of anonymous unions, which are allowed as of C11, as examples and encouragement for future code, and to test compilers. This commit changes the DSMRegistryEntry struct. Reviewed-by: Peter Eisentraut Discussion: https://postgr.es/m/aNKsDg0fJwqhZdXX%40nathan Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/74b41f5a77b8586356d02227c92e7e47380ac228 Modified Files -- src/backend/storage/ipc/dsm_registry.c | 18 +- 1 file changed, 9 insertions(+), 9 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_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ea06f97eeb335ca8dd70be5f8c11a32ec4f3eb12 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: Englishify comment wording
Englishify comment wording Switch to using the English word here rather than using a verbified function name. The full word still fits within a single comment line, so it's probably better just to use that instead of trying to shorten it, which might cause confusion. Author: Rafia Sabih Discussion: https://postgr.es/m/CA+FpmFe7LnRF2NA_QfARjkSWme4mNt+Udwbh2Yb=zzm35ji...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/86d118f9a60c6aafe1a6331fdf80455df24f32ae Modified Files -- src/include/nodes/memnodes.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Fix typo in pgstat_relation.c header comment
Fix typo in pgstat_relation.c header comment Looks like a copy and paste error from pgstat_function.c Author: Bertrand Drouvot Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/91df0465a69ddd249a548a63ee9d4aef6f984bf0 Modified Files -- src/backend/utils/activity/pgstat_relation.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Fix incorrect message-printing in win32security.c.
Fix incorrect message-printing in win32security.c. log_error() would probably fail completely if used, and would certainly print garbage for anything that needed to be interpolated into the message, because it was failing to use the correct printing subroutine for a va_list argument. This bug likely went undetected because the error cases this code is used for are rarely exercised - they only occur when Windows security API calls fail catastrophically (out of memory, security subsystem corruption, etc). The FRONTEND variant can be fixed just by calling vfprintf() instead of fprintf(). However, there was no va_list variant of write_stderr(), so create one by refactoring that function. Following the usual naming convention for such things, call it vwrite_stderr(). Author: Bryan Green Reviewed-by: Tom Lane Discussion: https://postgr.es/m/CAF+pBj8goe4fRmZ0V3Cs6eyWzYLvK+HvFLYEYWG=tzam+tw...@mail.gmail.com Backpatch-through: 13 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f91666c836dd8915f0ee67a90c5d76e10bfde838 Modified Files -- src/backend/utils/error/elog.c | 16 +--- src/include/utils/elog.h | 1 + src/port/win32security.c | 4 ++-- 3 files changed, 16 insertions(+), 5 deletions(-)
pgsql: Fix StatisticsObjIsVisibleExt() for pg_temp.
Fix StatisticsObjIsVisibleExt() for pg_temp. Neighbor get_statistics_object_oid() ignores objects in pg_temp, as has been the standard for non-relation, non-type namespace searches since CVE-2007-2138. Hence, most operations that name a statistics object correctly decline to map an unqualified name to a statistics object in pg_temp. StatisticsObjIsVisibleExt() did not. Consequently, pg_statistics_obj_is_visible() wrongly returned true for such objects, psql \dX wrongly listed them, and getObjectDescription()-based ereport() and pg_describe_object() wrongly omitted namespace qualification. Any malfunction beyond that would depend on how a human or application acts on those wrong indications. Commit d99d58cdc8c0b5b50ee92995e8575c100b1a458a introduced this. Back-patch to v13 (all supported versions). Reviewed-by: Nathan Bossart Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a95393ecdb23563bd47eeb2c943640c88592d82b Modified Files -- src/backend/catalog/namespace.c | 3 +++ src/test/regress/expected/stats_ext.out | 14 ++ src/test/regress/sql/stats_ext.sql | 8 3 files changed, 25 insertions(+)
pgsql: Keep track of what RTIs a Result node is scanning.
Keep track of what RTIs a Result node is scanning. Result nodes now include an RTI set, which is only non-NULL when they have no subplan, and is taken from the relid set of the RelOptInfo that the Result is generating. ExplainPreScanNode now takes notice of these RTIs, which means that a few things get schema-qualified in the regression tests that previously did not. This makes the output more consistent between cases where some part of the plan tree is replaced by a Result node and those where this does not happen. Likewise, pg_overexplain's EXPLAIN (RANGE_TABLE) now displays the RTIs stored in a Result node just as it already does for other RTI-bearing node types. Result nodes also now include a result_reason, which tells us something about why the Result node was inserted. Using that information, EXPLAIN now emits, where relevant, a "Replaces" line describing the origin of a Result node. The purpose of these changes is to allow code that inspects a Plan tree to understand the origin of Result nodes that appear therein. Discussion: http://postgr.es/m/CA+TgmoYeUZePZWLsSO+1FAN7UPePT_RMEZBKkqYBJVCF1s60=w...@mail.gmail.com Reviewed-by: Alexandra Wang Reviewed-by: Richard Guo Reviewed-by: Tom Lane Reviewed-by: Junwang Zhao Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f2bae51dfd5b2edc460c86071c577a45a1acbfd7 Modified Files -- contrib/file_fdw/expected/file_fdw.out | 1 + contrib/pg_overexplain/expected/pg_overexplain.out | 6 +- contrib/pg_overexplain/pg_overexplain.c| 12 ++ contrib/postgres_fdw/expected/postgres_fdw.out | 9 +- src/backend/commands/explain.c | 102 +++ src/backend/optimizer/plan/createplan.c| 117 +++-- src/backend/optimizer/plan/setrefs.c | 2 + src/include/nodes/plannodes.h | 22 src/test/regress/expected/aggregates.out | 51 +--- src/test/regress/expected/case.out | 21 +-- src/test/regress/expected/explain.out | 8 ++ src/test/regress/expected/generated_virtual.out| 25 ++-- src/test/regress/expected/groupingsets.out | 3 +- src/test/regress/expected/inherit.out | 28 ++-- src/test/regress/expected/join.out | 143 - src/test/regress/expected/merge.out| 3 +- src/test/regress/expected/partition_aggregate.out | 21 +-- src/test/regress/expected/partition_join.out | 35 ++--- src/test/regress/expected/partition_prune.out | 141 +++- src/test/regress/expected/predicate.out| 33 +++-- src/test/regress/expected/rowsecurity.out | 13 +- src/test/regress/expected/rowtypes.out | 6 +- src/test/regress/expected/select.out | 7 +- src/test/regress/expected/subselect.out| 17 ++- src/test/regress/expected/tsrf.out | 6 +- src/test/regress/sql/explain.sql | 1 + src/tools/pgindent/typedefs.list | 1 + 27 files changed, 567 insertions(+), 267 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_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b753be38a4a239b7cd4d2c289d8737c955c46f6f 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: 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 -- master Details --- https://git.postgresql.org/pg/commitdiff/12609fbacb007698ec91101b6464436506518346 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: 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_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c160fd46910e7ad9490578b453847f06ffb3f5ee Modified Files -- src/backend/access/nbtree/nbtutils.c | 1 - 1 file changed, 1 deletion(-)
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_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c3b9e565137b187cd9b271fff366075020df6b1d Modified Files -- doc/src/sgml/ref/alter_table.sgml | 34 -- 1 file changed, 16 insertions(+), 18 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_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/af302ff6b84ab136533e98b69f645fc271338915 Modified Files -- src/backend/access/nbtree/nbtutils.c | 1 - 1 file changed, 1 deletion(-)
pgsql: Improve TAP tests by replacing ok() with better Test::More funct
Improve TAP tests by replacing ok() with better Test::More functions The TAP tests whose ok() calls are changed in this commit were relying on perl operators, rather than equivalents available in Test::More. For example, rather than the following: ok($data =~ qr/expr/m, "expr matching"); ok($data !~ qr/expr/m, "expr not matching"); The new test code uses this equivalent: like($data, qr/expr/m, "expr matching"); unlike($data, qr/expr/m, "expr not matching"); A huge benefit of the new formulation is that it is possible to know about the values we are checking if a failure happens, making debugging easier, should the test runs happen in the buildfarm, in the CI or locally. This change leads to more test code overall as perltidy likes to make the code pretty the way it is in this commit. Author: Sadhuprasad Patro Discussion: https://postgr.es/m/caff0-chhwnx_cv2uy7tkjodubeogprjpw4rpf1jqb16_1bu...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/fabb33b351c2504a1985f9a1cdf697924cd5f023 Modified Files -- contrib/amcheck/t/004_verify_nbtree_unique.pl | 20 ++- contrib/pg_visibility/t/002_corrupt_vm.pl | 2 +- src/bin/initdb/t/001_initdb.pl | 6 +- src/bin/pg_basebackup/t/040_pg_createsubscriber.pl | 2 +- src/bin/pg_combinebackup/t/010_hardlink.pl | 4 +- src/bin/pg_dump/t/002_pg_dump.pl | 6 +- src/bin/pg_dump/t/005_pg_dump_filterfile.pl| 135 + src/bin/pgbench/t/001_pgbench_with_server.pl | 33 +++-- src/bin/psql/t/001_basic.pl| 2 +- src/bin/scripts/t/020_createdb.pl | 4 +- .../libpq/t/003_load_balance_host_list.pl | 11 +- src/interfaces/libpq/t/004_load_balance_dns.pl | 11 +- src/test/modules/test_aio/t/002_io_workers.pl | 5 +- .../test_misc/t/001_constraint_validation.pl | 123 +++ src/test/modules/test_misc/t/002_tablespace.pl | 40 +++--- src/test/modules/test_pg_dump/t/001_base.pl| 6 +- src/test/modules/xid_wraparound/t/002_limits.pl| 2 +- src/test/recovery/t/001_stream_rep.pl | 18 +-- src/test/recovery/t/003_recovery_targets.pl| 9 +- src/test/recovery/t/005_replay_delay.pl| 6 +- src/test/recovery/t/006_logical_decoding.pl| 11 +- src/test/recovery/t/020_archive_status.pl | 4 +- src/test/recovery/t/024_archive_recovery.pl| 5 +- .../recovery/t/035_standby_logical_decoding.pl | 15 ++- .../recovery/t/040_standby_failover_slots_sync.pl | 33 +++-- .../recovery/t/044_invalidate_inactive_slots.pl| 4 +- src/test/subscription/t/001_rep_changes.pl | 24 ++-- src/test/subscription/t/007_ddl.pl | 15 ++- src/test/subscription/t/013_partition.pl | 35 +++--- src/test/subscription/t/027_nosuperuser.pl | 5 +- src/test/subscription/t/031_column_list.pl | 5 +- src/test/subscription/t/035_conflicts.pl | 47 --- 32 files changed, 393 insertions(+), 255 deletions(-)
pgsql: doc: Clarify when backend_xmin in pg_stat_replication can be NUL
doc: Clarify when backend_xmin in pg_stat_replication can be NULL. Improve the documentation of pg_stat_replication to explain when the backend_xmin column becomes NULL. This happens when a replication slot is used (the xmin is then shown in pg_replication_slots) or when hot_standby_feedback is disabled. Author: Renzo Dani Reviewed-by: Fujii Masao Discussion: https://postgr.es/m/CA+XOKQAMXzskpdUmj2sg03_5fmiXc2Gs0r3TX1_rmcFcqh+=x...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e64aa1a39d4b8a9502be8ed8dfd67efd6f6acf28 Modified Files -- doc/src/sgml/monitoring.sgml | 4 1 file changed, 4 insertions(+)
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_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/32b95fc71b5825ad1722b821ae2508657970ce79 Modified Files -- src/backend/replication/pgoutput/pgoutput.c | 29 - 1 file changed, 24 insertions(+), 5 deletions(-)
pgsql: Make some use of anonymous unions [reorderbuffer xact_time]
Make some use of anonymous unions [reorderbuffer xact_time] Make some use of anonymous unions, which are allowed as of C11, as examples and encouragement for future code, and to test compilers. This commit changes the ReorderBufferTXN struct. Reviewed-by: Chao Li Discussion: https://www.postgresql.org/message-id/flat/f00a9968-388e-4f8c-b5ef-5102e962d997%40eisentraut.org Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/57d46dff9b0ba8dc50fb37166373ea7638ecd2b9 Modified Files -- contrib/test_decoding/test_decoding.c | 12 ++-- src/backend/replication/logical/proto.c | 14 +++--- src/backend/replication/logical/reorderbuffer.c | 14 +++--- src/backend/replication/pgoutput/pgoutput.c | 2 +- src/include/replication/reorderbuffer.h | 2 +- 5 files changed, 22 insertions(+), 22 deletions(-)
pgsql: Remove unused parameter from find_window_run_conditions()
Remove unused parameter from find_window_run_conditions() ... and check_and_push_window_quals(). Similar to 4be9024d5, but it seems there was yet another unused parameter. Author: Matheus Alcantara Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b91067c8995235445d76353bcd218ef383fe970d Modified Files -- src/backend/optimizer/path/allpaths.c | 21 + 1 file changed, 9 insertions(+), 12 deletions(-)
