Conversation
The postmaster test 004_negotiate.pl could fail due to IO::Socket::INET gone missing, in environments that cannot use Unix sockets. Oversight in the backport done in 6dffaeb, so like the other commit this is applied across the v14~17 range. Per buildfarm member drongo. Security: CVE-2026-6479 Backpatch-through: 14
Previously, pg_stat_progress_copy in the subscriber could continue to show the initial COPY operation for logical replication table synchronization as active even after the data copy had finished. The stale progress entry remained visible until synchronization caught up with the publisher. This happened because the table synchronization code called BeginCopyFrom() and CopyFrom(), but failed to call EndCopyFrom() afterward. This commit fixes the issue by adding the missing EndCopyFrom() call so that the COPY progress state in the subscriber is cleared as soon as the initial data copy completes. Backpatch to all supported branches. Author: Shinya Kato <shinya11.kato@gmail.com> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: ChangAo Chen <cca5507@qq.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Discussion: https://postgr.es/m/CAOzEurQKuy3RiPkd=25PEwEzaqHuGvEOf=X7vaVzhgNjaukYzA@mail.gmail.com Backpatch-through: 14
Two cases fixed by 2b5ba2a were not covered, to emulate the handling of corrupted data, for: - set control bit with a valid 2-byte match tag where offset is 0. - set control bit with a valid 2-byte match tag where offset exceeds output written. Oversight in 67d318e. Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com> Discussion: https://postgr.es/m/agF4xkIdRcrCIprs@paquier.xyz Backpatch-through: 14
When an UPDATE statement triggers check_foreign_key() with the action set to "cascade", it generates more UPDATE statements to modify the key values in referencing relations. If a new key value is NULL, SPI_getvalue() returns a NULL pointer, which is subsequently passed to quote_literal_cstr(), causing a segfault. To fix, skip quoting when a new key value is NULL and insert an unquoted NULL keyword instead. Oversight in commit 260e977. While the refint documentation recommends marking primary key columns NOT NULL, the aforementioned scenario accidentally worked on platforms where snprintf() substitutes "(null)" for NULL pointers. Note that for character-type columns, the old code quoted "(null)" as a string literal, so this didn't always produce correct results. But it still seems better to fix this than to reject cases that previously worked. Reported-by: Nikita Kalinin <n.kalinin@postgrespro.ru> Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com> Reviewed-by: Pierre Forstmann <pierre.forstmann@gmail.com> Discussion: https://postgr.es/m/19476-bd04ea6241345303%40postgresql.org Backpatch-through: 14
These tests have been removed by 906ea10, due to some of them being unstable in the buildfarm with low max_stack_depth values. They are now reworked so as they should be more portable. The tests to cover the findoprnd() overflows use a balanced tree to avoid using too much stack, per a suggestion and an investigation by Tom Lane. Note: This is initially applied only on HEAD; a backpatch will follow should the buildfarm be fine with the situation. Discussion: https://postgr.es/m/agZc6XecyE7E7fep@paquier.xyz Backpatch-through: 14
This mention of memcpy() should of course have said memcmp(). Reported-by: chris@chrullrich.net Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/177883653690.764749.14038057906859461991@wrigleys.postgresql.org Backpatch-through: 14
Three locations use Assert() to guard against a mismatch between the number of columns advertised in the RELATION message and the number actually received in the subsequent INSERT/UPDATE tuple message. Since these values originate from the publisher, the check must survive into production builds. A malicious or buggy publisher can send a RELATION claiming N columns and an INSERT claiming M < N columns. The subscriber's apply worker indexes into colvalues[]/colstatus[] using column indices from the RELATION message's attribute map, causing a heap out-of-bounds read when the tuple's column array is smaller than expected. We've looked, without success, for a scenario in which the publisher holds sufficient control over these out-of-bounds bytes to exploit this or even to reach a SIGSEGV. Despite not finding one, the code has been fragile. Back-patch to v14 (all supported versions). Reported-by: Varik Matevosyan <varikmatevosyan@gmail.com> Author: Varik Matevosyan <varikmatevosyan@gmail.com> Discussion: https://postgr.es/m/CA+bBoog3cCogktzfLb9bppUByu-10B3CFp8u=iKXG_OvtAguCw@mail.gmail.com Backpatch-through: 14
Commit c37b3d0 attempted to preserve group permissions on pg_recvlogical output files when group access was enabled on the source cluster. However, the output files were still created with a fixed S_IRUSR | S_IWUSR mode, preventing group-read permissions from being applied. This commit fixes the issue by creating output files with pg_file_create_mode instead of a hard-coded mode. This allows pg_recvlogical to correctly preserve group permissions from the source cluster. Backpatch to all supported branches. Author: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Srinath Reddy Sadipiralla <srinath2133@gmail.com> Discussion: https://postgr.es/m/CAHGQGwHhpizYzMo3nFP4GkNMueSNMY3QfC-gBN1VTXtuiANDvw@mail.gmail.com Backpatch-through: 14
When reusing an existing WAL receiver after it has reached WALRCV_WAITING for new instructions, RequestXLogStreaming() copied PrimaryConnInfo into WalRcv->conninfo before switching the state to WALRCV_RESTARTING. At that point ready_to_display could still be true, so pg_stat_wal_receiver could expose the raw connection string, including sensitive fields, but it should only show the user-displayable version of the connection string. WALRCV_RESTARTING does not establish a new connection. The waiting WAL receiver reuses its existing connection and only needs a new startpoint and timeline, so there is no need to copy the raw connection string into shared memory again. Let's only copy conninfo when launching a new WAL receiver after WALRCV_STOPPED, not while waiting for instructions. This commit adds coverage for the case fixed by this commit to the timeline-switch test by verifying that the WAL receiver conninfo remains consistent across the jump. Backpatch all the way down, as this issue is possible since pg_stat_wal_receiver has been introduced. Author: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://postgr.es/m/EF91FF76-1E2B-4F3B-9162-290B4DC517FF@gmail.com Backpatch-through: 14
The check for the minimum expected bytea size of a MVDependencies object was using SizeOfItem() for its calculation. This macro uses the number of attributes in a single dependency. This minimum size calculation should be based on MinSizeOfItems(), that computes the minimum expected size as the header plus the minimally-sized number of dependency items. Oversight in d08c44f. Author: Ilia Evdokimov <ilya.evdokimov@tantorlabs.com> Discussion: https://postgr.es/m/4b8d299d-2505-4c30-bf80-0f697410db35@tantorlabs.com Backpatch-through: 14
Given a WHERE clause like "int[] @@ query_int" or "query_int ~~ int[]" where the query_int side is a table column having statistics, _int_matchsel() exited without remembering to free the statistics tuple. This would typically lead to warnings about cache refcount leakage, like WARNING: resource was not closed: cache pg_statistic (73), tuple 42/12 has count 1 It's been wrong since this code was added, in commit c6fbe6d. Bug: #19492 Reported-by: Man Zeng <zengman@halodbtech.com> Author: Man Zeng <zengman@halodbtech.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/19492-ddcd0e22399ef85a@postgresql.org Backpatch-through: 14
This commit fixes two bugs in ProcKill()'s lock-group teardown freelist publication: * a double push of the leader's PGPROC that corrupts the freelist. * a leak of the last follower's PGPROC slot. ProcKill()'s lock-group teardown had two PGPROC freelist updates scattered through the function, done under two separate freeProcsLock acquisitions: * A follower's push of the leader's PGPROC, done when a follower is the last group member exiting. * Every backend's self-push at the bottom of the function. The two freelist updates were coordinated only by inspecting proc->lockGroupLeader, which a follower could clear as a side effect of pushing the leader. This coordination was broken. For example, with two concurrent backends: * The follower clears leader->lockGroupLeader and pushes the leader's PGPROC under leader_lwlock. * The follower does not clear its own proc->lockGroupLeader, being skipped. * When the leader reaches the bottom of ProcKill(), it sees a NULL proc->lockGroupLeader (the follower cleared it) and pushes itself, causing a second dlist_push_tail() of the same node onto the same freelist. * The follower at the bottom sees its own proc->lockGroupLeader being not NULL (never cleared) and skips its own push, causing its own slot to leak. This commit refactors the freelist manipulation to be done in two distinct phases, each step using its own lock acquisition to ensure that each freelist operation happens in an isolated manner for each backend (follower or leader): - First, under a single leader_lwlock acquisition, check the state of the lock-group. Depending on if we are dealing with a follower and/or a leader, and if the leader has exited before a follower, then set some state booleans that define which actions should be taken with the freelist. - Second, under a single freeProcsLock acquisition, perform the cleanup actions, self-push of a backend and/or push of the leader back to the freelist. This is an old issue, dating back to 9.6 where parallel workers and lock grouping has been added. Author: Vlad Lesin <vladlesin@gmail.com> Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru> Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://postgr.es/m/d2983796-2603-41b7-a66e-fc8489ddb954@gmail.com Backpatch-through: 14
DisownLatch() was executed after the PGPROC entry of the process terminated is pushed back into a freelist. A newly-forked backend that recycles the slot could call OwnLatch() and PANIC with a "latch already owned by PID", taking down the server. There were two scenarios related to lock groups where this issue could be reached: * A follower pushes the leader's PGPROC back to the freelist while the leader has not yet called DisownLatch() in its own ProcKill(). * A leader outliving all its followers pushes its own PGPROC onto the freelist before reaching DisownLatch(), which would be the most common scenario. This issue is fixed by calling SwitchBackToLocalLatch() and DisownLatch() at an earlier phase of ProcKill(), before any freelist manipulation happens, so that the slot of the backend terminated is never exposed as owning a latch. Note that pgstat_reset_wait_event_storage() is kept at a later stage. An upcoming commit will take advantage of that by introducing a test able to check the original PANIC scenario. Author: Vlad Lesin <vladlesin@gmail.com> Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru> Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://postgr.es/m/d2983796-2603-41b7-a66e-fc8489ddb954@gmail.com Backpatch-through: 14
Commit 77dff5d introduced a SimpleLruWriteAll() call when replaying multixact WAL records generated by older minor versions. However, SimpleLruWriteAll() acquires the SLRU lock and on v16 and below, it's called while already holding the lock, leading to self-deadlock. Version 17 and 18 did not have that problem, because in those versions the lock is acquired later in the function. To fix, acquire MultiXactOffsetSLRULock later in RecordNewMultiXact(), at the same place where it's acquired on version 17 and 18. Author: Andrey Borodin <x4mmm@yandex-team.ru> Reported-by: Radim Marek <radim@boringsql.com> Discussion: https://www.postgresql.org/message-id/19490-9c59c6a583513b99@postgresql.org Backpatch-through: 14-16
When creating a relation with a dropped column, we called recordDependencyOn() also on the datatype of the dropped column, which is always InvalidOid. In versions 15 and above, that was harmless because recordDependencyOn() considers InvalidOid as a pinned object, and skips over it. On version 14, isPinnedObject() does not consider InvalidOid as pinned, so we created a bogus pg_depend entry with refobjectid == 0. As far as I can tell, the only case when AddNewAttributeTuples() is called with dropped columns is when performing a table-rewriting ALTER TABLE command. That temporarily creates a new relation with the same columns, including dropped ones, then swaps the relations, and drops the newly created table again. So even on version 14, the bogus pg_depend entry was only on the transient relation that was dropped at the end of the ALTER TABLE command, which was harmless. Even though this is harmless, let's be tidy, similar to commit 713bce9. The reason I noticed this now and why I backported this, is because the next commit will add code to acquire locks on the referenced objects, and we don't want to acquire a lock on InvalidOid. Discussion: https://postgr.es/m/ZiYjn0eVc7pxVY45@ip-10-97-1-34.eu-west-3.compute.internal Backpatch-through: 14
Concurrent DDL can leave behind objects referencing other objects that no longer exist. This can happen if an object is dropped, while a new object that depends on it is created concurrently. For example: session 1: BEGIN; CREATE FUNCTION myschema.myfunc() ...; session 2: DROP SCHEMA myschema; session 1: COMMIT; DROP SCHEMA does check that there are no objects dependending on the schema being dropped, but it does not see objects being concurrently created by other sessions. Even if it did, this scenario would still fail: session 1: BEGIN: DROP SCHEMA myschema; session 2: CREATE FUNCTION myschema.myfunc() ...; session 1: COMMIT; When the DROP SCHEMA runs, the schema was empty, but the new function is created in it before the dropping transaction completes. The CREATE FUNCTION does not see that the schema is concurrently being dropped. In both of these scenarios, the function is left behind in the schema that no longer exists. To fix, acquire AccessShareLock on all referenced objects when recording dependencies. This conflicts with the AccessExclusiveLock taken by DROP, preventing the race. After acquiring the lock, verify that the object still exists, and if it was dropped concurrently, report an error. We already had such a mechanism for shared dependencies, but for some reason we didn't do it for in-database dependendies. Ideally the locks would be acquired much earlier when creating a new object, but that will require modifying a lot of callers. This check while recording the dependency is a nice wholesale protection, and even if we change all the CREATE commands to acquire locks earlier, it's still good to have this as a backstop to catch any cases where we forgot to do so. The patch adds a few tests for some cases that left behind orphaned objects before this. It also adds a test for roles, which already had such protection, although that test is partially disabled because the error message includes an OID which is not predictable. Author: Bertrand Drouvot <bertranddrouvot.pg@gmail.com> Reviewed-by: Heikki Linnakangas <heikki.linnakangas@iki.fi> Discussion: https://postgr.es/m/ZiYjn0eVc7pxVY45@ip-10-97-1-34.eu-west-3.compute.internal Backpatch-through: 14
With address sanitizer's stack-use-after-return check, stack variables are moved to heap allocations, to allow to detect references to the memory at a later time. That broke our stack-depth check, which is why we had to disable detect_stack_use_after_return in CI. Luckily __builtin_frame_address() works correctly, even under asan, so use that. We started using __builtin_frame_address() with de447bb, however as of that commit we just used it for the stack base address, not for the value to compare to the base address. Now we use it for both. When building without __builtin_frame_address() support, we continue to use stack variables for the stack depth determination. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/2kk4z4odvuyrg7qlwjd7ft4eron4cle4btb33v4qatgsdkayir@gj6e62rgsel4 Backpatch-through: 14
Reported-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Discussion: https://www.postgresql.org/message-id/20260528.114608.488039299811669368.horikyota.ntt@gmail.com Backpatch-through: 14
The code failed to initialize the second isnull argument passed to FunctionCallInvoke(). This is harmless for existing in-core extended hash support functions, since FunctionCallInvoke() does not use the value (note that all the in-core extended hash functions are strict), examining only the argument values. However, extension-provided extended hash functions could be affected if they inspect PG_ARGISNULL(1). Oversight in 01e658f. Author: Man Zeng <zengman@halodbtech.com> Discussion: https://postgr.es/m/tencent_7818173C01E01836109848C3@qq.com Backpatch-through: 14
When releasing an ephemeral replication slot, ReplicationSlotRelease() drops the slot via ReplicationSlotDropAcquired(). However, after dropping the slot, ReplicationSlotRelease() continued to use its local "slot" pointer, which still referenced the dropped slot's former shared-memory entry. It could then update fields such as effective_xmin in that entry. Once an ephemeral slot has been dropped (via ReplicationSlotDropAcquired()), its slot array entry can be reused immediately by another backend creating a new slot. As a result, those updates could corrupt the state of an unrelated replication slot. Fix by skipping those shared-memory updates for phemeral slots and performing them only for non-ephemeral slots, whose shared-memory entries remain valid after release. Backpatch to all supported versions. Author: Zhijie Hou <houzj.fnst@fujitsu.com> Reviewed-by: Masao Fujii <masao.fujii@gmail.com> Reviewed-by: Srinath Reddy Sadipiralla <srinath2133@gmail.com> Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com> Discussion: https://postgr.es/m/TY4PR01MB177184FF9EE916F577E1F554194082@TY4PR01MB17718.jpnprd01.prod.outlook.com Backpatch-through: 14
Like 8f1791c, this fixes a case of implicitly casting away const by not treating the result of strrchr() on a const pointer as const. This was missed at the time because the machines reporting those warnings weren't building with --with-llvm. While here, clean up another infelicity: in the probably- impossible case that the input string contains only one dot, this function would call pnstrdup() with a length of -1 and thereby emit a module name equal to the function name. It seems to me we should emit modname = NULL instead. Also remove a useless Assert and two redundant assignments. Back-patch, as 8f1791c was, so that users of back branches don't see this warning when building with late-model gcc. Reported-by: hubert depesz lubaczewski <depesz@depesz.com> Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/aiGNJ89PBqvq2Yyz@depesz.com Backpatch-through: 14
This commit addresses two related issues: tsvector_filter() assumed it could print an incorrect weight value with %c. This could result in an invalidly-encoded error message if the database encoding is multibyte and the char value has its high bit set. Weight values that are ASCII control characters could render illegibly too. Fix by printing such values in octal (\ooo), similarly to how charout() would render them. tsvector_setweight() and tsvector_setweight_by_filter() reported the same unrecognized-weight error condition with elog(), as though it were an internal error. That'd not translate, would produce an unwanted XX000 SQLSTATE code, and also reported the bad value as a decimal integer which seems unhelpful. Fix by refactoring so that all three functions share one copy of the code that interprets a weight argument. The invalid-encoding aspect seems to me (tgl) to justify back-patching. Author: Ewan Young <kdbase.hack@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/CAON2xHNaeLAUzRCXL5AmXLcXaSE_gWAVjWQRmLzc_oZ=1_Vf4Q@mail.gmail.com Backpatch-through: 14
The NFC recomposition incorrectly included TBASE as a valid T syllable, which is incorrect based on the Unicode specification (TBASE is one below the start of the range, range beginning at U+11A8). This would cause the TBASE to be silently swallowed in the normalization, leading to an incorrect result. A couple of regression tests are added to check more patterns with Hangul recomposition and decomposition, on top of a test to check the problem with TBASE. Diego has submitted the code fix, and I have written the tests. Author: Diego Frias <mail@dzfrias.dev> Co-authored-by: Michael Paquier <michael@paquier.xyz> Discussion: https://postgr.es/m/B92ED640-7D4A-4505-B09F-3548F58CBB16@dzfrias.dev Backpatch-through: 14
Presently, refint stores plans in a per-backend cache to avoid re-preparing in each call. This has a few problems. For one, check_foreign_key() embeds the new key values in its cascade-UPDATE queries, so a cached plan reuses the values from preparation. Also, the cache is never invalidated, so it can return stale entries that cause other problems. There may very well be more bugs lurking. We could spend a lot of time trying to address all these problems, but this module is primarily intended as sample code, and by all indications, it sees minimal use. Furthermore, there is a growing consensus for removing refint in v20. However, since we'll need to support it on the back-branches for a while longer, it probably still makes sense to fix some of the more egregious bugs. Therefore, let's just remove refint's plan cache entirely. That means we'll re-prepare on every call, but that seems quite unlikely to bother anyone. On v17 and older versions, the regression test for triggers fails after this change, so I've borrowed pieces of commit 8cfbdf8 to fix it. Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com> Discussion: https://postgr.es/m/CAJTYsWXU%2BfhuzrEd_bnrxyGH3%2Bny8QRQC2QHf3ws6s9iki3c2Q%40mail.gmail.com Backpatch-through: 14
heap_force_common() declared a boolean array indexed with an OffsetNumber for a size of MaxHeapTuplesPerPage. OffsetNumbers are 1-based, so an input TID whose offset number equals MaxHeapTuplesPerPage wrote one byte past the end of the stack array, crashing the server. Like heapam_handler.c, this commit changes the array so as it uses a 0-based index, substracting one from the OffsetNumbers. Reported-by: Wang Yuelin <violin0613@tju.edu.cn> Reviewed-by: Ashutosh Sharma <ashu.coek88@gmail.com> Discussion: https://postgr.es/m/20260604002256.40f1fd544@smtp.qiye.163.com Backpatch-through: 14
When a table's columns are narrower than the record header line, the expanded aligned format produced misaligned output because the data column width was not adjusted to match the record header width, leading to output like: +-[ RECORD 1 ]-+ | a | 10 | | b | 20 | +---+----+ This commit adjusts the output so as the column width match with the header line, giving: +-[ RECORD 1 ]-+ | a | 10 | | b | 20 | +---+----------+ Author: Pavel Stehule <pavel.stehule@gmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Discussion: https://postgr.es/m/CAFj8pRCzGpsr9zTHbtTd4mGh2YPJqOEgLgt8JLiopuYA9_1xGw@mail.gmail.com Backpatch-through: 14
Previously, ecpg accepted multiple descriptor header items in GET DESCRIPTOR and SET DESCRIPTOR, but generated broken C code when they were used. Although the grammar allowed this syntax, the implementation did not actually support it. This commit tightens the ecpg grammar so the header form of GET/SET DESCRIPTOR accepts only a single header item, matching the implementation and preventing generation of broken C code. Also update the documentation synopsis accordingly. Backpatch to all supported versions. Author: Masashi Kamura <kamura.masashi@fujitsu.com> Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com> Reviewed-by: Lakshmi G <lakshmigcdac@gmail.com> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/OS9PR01MB13174AD7D1829D0644B6BB90E9447A@OS9PR01MB13174.jpnprd01.prod.outlook.com Backpatch-through: 14
The security team has received a couple of reports about potential SQL injection via refint's trigger arguments. We discussed this while preparing CVE-2026-6637 and concluded that forcibly quoting these arguments is more likely to break working code than to prevent exploits. Unlike data values, the table/column names come from trigger arguments, and there is little reason for a trigger author to put hostile inputs into those arguments. So, let's document it accordingly. Reported-by: Nikolay Samokhvalov <nik@postgres.ai> Reported-by: Alex Young <alex000young@gmail.com> Reported-by: Satyanarayana Narlapuram <satyanarlapuram@gmail.com> Suggested-by: Noah Misch <noah@leadboat.com> Reviewed-by: Noah Misch <noah@leadboat.com> Reviewed-by: Fujii Masao <masao.fujii@oss.nttdata.com> Reviewed-by: Christoph Berg <myon@debian.org> Reviewed-by: Satyanarayana Narlapuram <satyanarlapuram@gmail.com> Discussion: https://postgr.es/m/ahXP7z7nsfGPOZ3T%40nathan Backpatch-through: 14
The operators for array_eq, record_eq, range_eq, and multirange_eq are all marked oprcanhash, but there's a pitfall: their hash functions can fail at runtime if the contained type(s) are not hashable. Therefore, the planner has to check hashability of the contained types before deciding it can use hashing in these cases. Not every place had gotten this memo, and noplace at all had considered the issue for ranges or multiranges. In particular we could attempt to use hashing for a ScalarArrayOpExpr on a container type when it won't actually work, leading to "could not identify a hash function ..." runtime failures. For the most part we should fix this in the lookup functions provided by lsyscache.c, to wit get_op_hash_functions and op_hashjoinable. But there's a problem: get_op_hash_functions is not passed the input data type it would need to check. We mustn't change the API of that exported function in a back-patched fix, and even if we wanted to, its call sites in the executor mostly don't have easy access to the required data type OID. Fortunately, the executor call sites don't actually need fixing, because it's expected that the planner verified hashability before building a plan that requires it. Therefore, leave get_op_hash_functions as-is and invent a wrapper function get_op_hash_functions_ext that does the additional checking needed in the planner's uses. We also need to fix hash_ok_operator (extending the fix in 6478896). While at it, neaten up a couple of places in lookup_type_cache where relevant code for multirange cases was written differently from the code for other container types. Note: while this touches pg_operator.dat, it's only to add oid_symbol macros. So there's no on-disk data change and no need for a catversion bump. Reported-by: Andrei Lepikhov <lepihov@gmail.com> Author: Andrei Lepikhov <lepihov@gmail.com> Co-authored-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/ed221f95-f09b-4a9c-b05b-e1fed621ec87@gmail.com Backpatch-through: 14
Previously, outlen was miscalculated if case_sensitive was false and str_tolower() changed the byte length of the string. If outlen was too large, pnstrdup() would stop at the NUL terminator, preventing overrun. But if outlen was too small, it would cause truncation. Fix by just removing outlen. It was only used in a single site, which could just as well use pstrdup(). Discussion: https://postgre.es/m/1101e1a3afbbabb503317069c40374b82e6f4cac.camel@j-davis.com Reviewed-by: Tristan Partin <tristan@partin.io> Backpatch-through: 14
Add check_stack_depth() to Jsonb_to_SV, SV_to_JsonbValue, PLyObject_FromJsonbContainer, and PLyObject_ToJsonbValue. Without this, deeply nested JSONB values can crash the backend with SIGSEGV instead of raising a proper error. Also add CHECK_FOR_INTERRUPTS() to the while loop in SV_to_JsonbValue that dereferences chains of Perl references, so that a circular reference (e.g. $x = \$x) can be cancelled by the user instead of spinning indefinitely. (We looked at detecting such circular references, but it seems more trouble than it's worth.) Author: Aleksander Alekseev <aleksander@tigerdata.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/CAJ7c6TPbjkzUk4qJ5dHvDNEz0hBuFue3A-XWz_=897z+BC+z8A@mail.gmail.com Backpatch-through: 14
The two-argument jsonb @? and @@ operators invoke the jsonpath executor with no variable set. In that case getJsonPathVariable() treated any "$name" reference as JSON null and continued evaluating, instead of reporting the variable as undefined. This produced incorrect results -- for example '42'::jsonb @? '$"x"' returned true -- and, for some malformed or hostile jsonpath expressions with deeply nested predicates, allowed essentially unbounded memory consumption that could get the backend killed by the OOM killer. Report the undefined variable as an error in this case as well, reusing the message already emitted when a variable is not found among supplied variables. This matches the behavior of v17 and later, where the jsonpath executor was reorganized. Stopping at the first undefined variable reference also resolves the reported memory-growth case. Note this is a user-visible change in the back branches: a jsonpath expression that references a variable while no variables are supplied now raises an error rather than silently evaluating it as NULL. The previous behavior was incorrect, so the change is judged worthwhile. Bug: #19458 Reported-by: Andrey Rachitskiy <pl0h0yp1@gmail.com> Author: Andrey Rachitskiy <pl0h0yp1@gmail.com> Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru> Reviewed-by: Nikita Malakhov <hukutoc@gmail.com> Reviewed-by: Amit Langote <amitlangote09@gmail.com> Discussion: https://postgr.es/m/19458-a69c98bc498333ba@postgresql.org Backpatch-through: 14-16
Commit 6678b58 fixed a wrong "Prev" link by changing the link generation code to use [position()=last()] instead of [last()] in the predicate on the union of reverse axes. Unfortunately, that caused documentation builds to take much longer. To fix, combine the "preceding" and "ancestor" steps into one "preceding" step and one "ancestor" step, and revert the predicate back to [last()]. The smaller union evades the libxml2 bug while avoiding the build time regression. Reported-by: Tom Lane <tgl@sss.pgh.pa.us> Tested-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/1132496.1781718007%40sss.pgh.pa.us Backpatch-through: 14
Add CHECK_FOR_INTERRUPTS() to the while loop in plperl_to_hstore() that dereferences chains of Perl references, so that a circular reference (e.g. $x = \$x) can be cancelled by the user instead of spinning indefinitely. (We looked at detecting such circular references, but it seems more trouble than it's worth.) This is a follow-up to da82fbb, which fixed the same issue in SV_to_JsonbValue() in jsonb_plperl. Author: Aleksander Alekseev <aleksander@tigerdata.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/CAJ7c6TPbjkzUk4qJ5dHvDNEz0hBuFue3A-XWz_=897z+BC+z8A@mail.gmail.com Backpatch-through: 14
Newer gcc warns that this "actual_arg_types" variable may be used uninitialized, but visual inspection indicates there's no bug. To silence the warning, initialize the variable to zeros. Bug: #19485 Reported-by: Hans Buschmann <buschmann@nidsa.net> Tested-by: Erik Rijkers <er@xs4all.nl> Tested-by: Hans Buschmann <buschmann@nidsa.net> Reviewed-by: Tristan Partin <tristan@partin.io> Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de> Discussion: https://postgr.es/m/19485-2b03231a775756f1%40postgresql.org Discussion: https://postgr.es/m/6c52a1a6612948519468d46cb224a8c4%40nidsa.net
pg_mkdir_p creates each missing path component with a stat() followed
by mkdir(). If the stat() reports the component as absent but another
process creates it in the window before this process's mkdir(), mkdir()
fails with EEXIST and pg_mkdir_p treated that as a hard error -- unlike
"mkdir -p", which is meant to be idempotent and race-tolerant.
This shows up when several processes concurrently create paths that
share an ancestor directory: for example, parallel initdb runs whose
data directories live under a common temporary directory. One process
wins the race to create the shared ancestor and the others fail with
could not create directory "...": File exists
Fix this race condition by first trying mkdir() and only attempting
stat() if it fails with EEXIST.
On Windows, there's an additional problem: stat() opens a file handle
and participates in share-mode locking, which means it can transiently
fail on a directory another process is concurrently creating. Use
GetFileAttributes() instead: it requests only FILE_READ_ATTRIBUTES
and is exempt from share-mode denial, so it reliably sees a
concurrently-created directory.
I (tgl) also chose to back-patch 039f7ee's effects on this function,
so that pgmkdirp.c remains identical in all live branches.
Author: Andrew Dunstan <andrew@dunslane.net>
Co-authored-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/3ca004de-e49b-4471-b8aa-fd656e70f68c@dunslane.net
Backpatch-through: 14
When ALTER TABLE ... ATTACH PARTITION matches partition indexes to the parent table's indexes, invalid indexes are skipped. This commit improves the documentation to describe what e90e9275f56 has changed: invalid indexes are skipped, and only valid indexes are considered for a match. Author: Mohamed Ali <moali.pg@gmail.com> Reviewed-by: Sami Imseih <samimseih@gmail.com> Discussion: https://postgr.es/m/CAGnOmWpAMaE-BOkpwM6mJnHcpS2QZ8yLSSaqmz+vryEsbCWWWA@mail.gmail.com Backpatch-through: 14
In get_perl_array_ref(), for a PostgreSQL::InServer::ARRAY object, we look up its "array" key with hv_fetch_string() and then inspect the returned SV. However, hv_fetch_string() returns a NULL pointer when the key is absent, and the code dereferenced that result without first checking whether the pointer itself was NULL. As a result, a plperl function returning a forged PostgreSQL::InServer::ARRAY object that lacks the "array" key would crash the backend with a segmentation fault. Fix this by checking the pointer returned by hv_fetch_string() before dereferencing it, matching how other callers in this file already guard the result. With the check in place, such an object falls through to the existing error report instead of crashing. Author: Xing Guo <higuoxing@gmail.com> Reviewed-by: Richard Guo <guofenglinux@gmail.com> Discussion: https://postgr.es/m/CACpMh+DYgcnqZwQLXXuxQcehJTd7T8UmKWSLsK4mFBEp9G2ajA@mail.gmail.com Backpatch-through: 14
…ng objects PL/Python and its hstore and jsonb transforms build SQL values from Python containers by calling Python C API functions that can return NULL, and in several places the result was used without first checking it. On the sequence side, PySequence_GetItem() is used when converting a returned sequence into a SQL array or composite value, when reading the argument list passed to plpy.execute() or plpy.cursor(), and when reading the list of type names given to plpy.prepare(). On the mapping side, the hstore and jsonb transforms call PyMapping_Size() and PyMapping_Items() and then index the result with PyList_GetItem() and PyTuple_GetItem(). All of these return NULL (or -1), with a Python exception set, for a broken object: for example one whose __getitem__() or items() raises, or which reports a length that disagrees with what it actually yields. The unchecked result was then dereferenced, crashing the backend. Fix this by checking the result of each call and reporting a regular error if it failed, so that the underlying Python exception is surfaced instead of taking down the session. Author: Richard Guo <guofenglinux@gmail.com> Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com> Discussion: https://postgr.es/m/CAMbWs49BKM9wP6m8bCXEpHwQKp7usvOGV6Jf=J7FYr_BCpxLqg@mail.gmail.com Backpatch-through: 14
Commit 0b7719f added regression tests that spell the language name as plpython3u. That works on the master branch, but on v14 the plpython tests must use the unversioned name plpythonu: the plpython3u extension is built only in Python 3 builds, and for those builds regress-python3-mangle.mk rewrites plpythonu to plpython3u in the test files. In a Python 2 build the new tests instead failed with "language \"plpython3u\" does not exist". Spell the language as plpythonu in the new tests, matching every other plpython test in this branch, so they work in both Python 2 and Python 3 builds. This is needed only in v14; later branches no longer support Python 2 and have dropped the mangling step. Per buildfarm member hippopotamus.
The float4 and float8 btree_gist opclasses compared keys with raw C operators (==, <, >). IEEE 754 makes every comparison involving NaN false, so GiST disagreed with the regular float comparison operators and with the btree opclass, which uses float[4|8]_cmp_internal() (so that all NaNs are equal and NaN sorts after every non-NaN value). In addition, the penalty and distance functions were not careful about NaNs, and the penalty functions could also misbehave for IEEE infinities. Wrong answers from the penalty functions would probably do no more than make the index non-optimal, but the distance mistakes were visible from SQL. To fix, make the comparison functions rely on the same NaN-aware comparison functions the core code uses, and rewrite the penalty and distance functions to follow the rules that NaNs are equal but maximally far away from non-NaNs. The penalty_num() code was formerly shared between integral and float cases, but I chose to make two copies so that the integral cases are not saddled with the extra logic for NaNs and infinities/overflows. I also rewrote it as static inline functions instead of an unreadable and uncommented macro. The float penalty functions were previously unreached by the regression tests, so add new test cases to exercise them. There's no on-disk format change, but users who have NaN entries in a btree_gist index would be well advised to reindex it. Bug: #19501 Bug: #19524 Reported-by: Man Zeng <zengman@halodbtech.com> Reported-by: Yuelin Wang <3020001251@tju.edu.cn> Author: Bill Kim <billkimjh@gmail.com> Co-authored-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/19501-3bff3bbc97f1e7c9@postgresql.org Discussion: https://postgr.es/m/19524-9559d302c8455664@postgresql.org Discussion: https://postgr.es/m/CAMQXxcgbtD2LXfX0tpgvOizxP-XxrCHV2ZDy4By_TZnJMsxXWQ@mail.gmail.com Backpatch-through: 14
Previously, MultiXactId wraparound hints suggested dropping stale replication slots. While that advice is appropriate for transaction ID wraparound, where replication slots can hold back XID horizons, it was misleading for MultiXactId wraparound. Following it could lead users to drop replication slots unnecessarily without helping resolve the MultiXactId wraparound condition. MultiXact cleanup is not directly delayed by replication slots. Instead, it depends on whether old MultiXactIds can still be seen as live by running transactions. This commit removes the replication slot advice from MultiXactId wraparound hints, and documents that stale replication slots are normally not relevant to resolving MultiXactId wraparound problems. Backpatch to all supported branches. BUG #18876 Reported-by: Haruka Takatsuka <harukat@sraoss.co.jp> Author: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/18876-0d0b53bad5a1f4c1@postgresql.org Backpatch-through: 14
Commit fb42123 extended \df to include procedures, but its tab completion continued not to show procedures. Update \df tab completion to include procedures as well. Backpatch to all supported versions. Author: Erik Wienhold <ewie@ewie.name> Reviewed-by: Surya Poondla <suryapoondla4@gmail.com> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/10fbfdfe-80f6-4ef9-b8b3-f7be0eb53a50@ewie.name Backpatch-through: 14
gbt_var_consistent() handled the <> (BtreeGistNotEqual) strategy without distinguishing leaf from internal pages, unlike every other strategy. In particular, it tried to apply the datatype-specific f_eq method, which is completely wrong since internal keys might not have the same representation as leaf keys. This led to OOB reads and potentially crashes, and most likely to wrong query results as well. On leaf pages we can apply the inverse of what the Equal strategy does. On internal pages, use a correct implementation of what the previous code intended: we can descend if the query value equals both bounds, *so long as the bounds aren't truncated*. With truncated bounds we don't quite know the range of what's below, so we must always descend. Adjust the code in gbt_num_consistent() to look similar, too. This fixes a performance buglet in that there's no need to do two comparisons on a leaf entry, but the main point is just to keep code consistency. Reported-by: 王跃林 <violin0613@tju.edu.cn> Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/AH*AvQCYKhQGVvPWi1GiU4oY.8.1781609375063.Hmail.3020001251@tju.edu.cn Backpatch-through: 14
ON SELECT rules must be named "_RETURN", while other kinds of rules must not be; this ancient restriction is depended on by various client code. We successfully enforced this convention in most places, but ALTER RULE allowed renaming a non-SELECT rule to "_RETURN". Notably, that would break dump/restore, since the eventual CREATE RULE command would reject the name. While at it, remove DefineQueryRewrite's hack to substitute "_RETURN" for the convention that was used before 7.3. We dropped other server-side code that supported restoring pre-7.3 dumps some time ago (notably in e58a599 and nearby commits), but this bit was missed. Bug: #19543 Reported-by: Adam Pickering <adamkpickering@gmail.com> Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/19543-461228e77f3b32fc@postgresql.org Backpatch-through: 14
Commit f3b0897 fixed some related problems, but overlooked this one. That commit first appeared in PostgreSQL 11, so back-patch to all supported branches. Backpatch-through: 14 Discussion: http://postgr.es/m/CA+TgmobsvQw3F+KRYT83=N3teh8D2t-oPR=U06QDZJE3viCJRg@mail.gmail.com Reviewed-by: Tender Wang <tndrwang@gmail.com> Reviewed-by: Ewan Young <kdbase.hack@gmail.com>
ParallelBackupStart() stored _beginthreadex()'s return value as the worker's thread handle without checking it. On failure that value is 0, which would later reach WaitForMultipleObjects() as a null handle, caught only by an Assert. The fork() path already calls pg_fatal() when it fails; do the same for _beginthreadex(), as pgbench does. Author: Bryan Green <dbryan.green@gmail.com> Discussion: https://www.postgresql.org/message-id/8c712d76-ecf7-4749-a6d8-dddc01f298ec@gmail.com Backpatch-through: 14
An extra check for pending bytes in the SSL layer has been part of pqReadReady() for a very long time (79ff2e9). But when GSS transport encryption was added, it didn't receive the same treatment. (As 79ff2e9 notes, "The bug that I fixed in this patch is exceptionally hard to reproduce reliably.") Without that check, it's possible to hit a hang in gssencmode, if the server splits a large libpq message such that the final message in a streamed response is part of the same wrapped token as the split message: DataRowDataRowDataRowDataRowDataRowData -- token boundary -- RowDataRowCommandCompleteReadyForQuery If the split message takes up enough memory to nearly fill libpq's receive buffer, libpq may return from pqReadData() before the later messages are pulled out of the PqGSSRecvBuffer. Without additional socket activity from the server, pqReadReady() (via pqSocketCheck()) will never again return true, hanging the connection. Pull the pending-bytes check into the pqsecure API layer, where both SSL and GSS now implement it. Note that this does not fix the root problem! Third party clients of libpq have no way to call pqsecure_read_is_pending() in their own polling. This just brings the GSS implementation up to par with the existing SSL workaround; a broader fix is left to a subsequent commit. In preparation for the broader fix, this patch already changes the *_read_pending() functions to return the number of bytes in the buffer rather than just a boolean. The current callers don't need that, but the subsequent fix will. Author: Jacob Champion <jacob.champion@enterprisedb.com> Discussion: https://postgr.es/m/CAOYmi%2BmpymrgZ76Jre2dx_PwRniS9YZojwH0rZnTuiGHCsj0rA%40mail.gmail.com Backpatch-through: 14
The previous commit strengthened a workaround for a hang when large
messages are split across TLS records/GSS tokens. Because that
workaround is implemented in libpq internals, it can only help us when
libpq itself is polling on the socket. In nonblocking situations,
where the client above libpq is expected to poll, the same bugs can
show up.
As a contrived example, consider a large protocol-2.0 error coming
back from a server during PQconnectPoll(), split in an odd way across
two records:
-- TLS record (8192-byte payload) --
EEEE[...repeated a total of 8192 times]
-- TLS record (8193-byte payload) --
EEEE[...repeated a total of 8192 times]\0
The first record will fill the first half of the libpq receive buffer,
which is 16k long by default. The second record completely fills the
last half with its first 8192 bytes, leaving the terminating NULL in
the OpenSSL buffer. Since we still haven't seen the terminator at our
level, PQconnectPoll() will return PGRES_POLLING_READING, expecting to
come back when the server has sent "the rest" of the data. But there
is nothing left to read from the socket; OpenSSL had to pull all of
the data in the 8193-byte record off of the wire to decrypt it.
A real server would probably not split up the records this way, nor
keep the connection open after sending a fatal connection error. But
servers that regularly use larger TLS records can get the libpq
receive buffer into the same state if DataRows are big enough, as
reported on the list. While the PostgreSQL server doesn't use larger
TLS records like that, other non-PostgreSQL servers that implement the
wire protocol are known to do that, as well as proxies that sit
between the server and the client
This is a layering violation. libpq makes decisions based on data in
the application buffer, above the transport buffer (whether SSL or
GSS), but clients are polling the socket below the transport buffer.
One way to fix this in a backportable way, without changing APIs too
much, is to ensure data never stays in the transport buffer. Then
pqReadData's postconditions will look similar for both raw sockets and
SSL/GSS: any available data is either in the application buffer, or
still on the socket.
Building on the prior commit, make pqReadData() to drain all pending
data from the transport layer into conn->inBuffer, expanding the
buffer as necessary. This is not particularly efficient from an
architectural perspective (the pqsecure_read() implementations take
care to fit their packets into the current buffer, and that effort is
now completely discarded), but it's hopefully easier to reason about
than a full rewrite would be for the back branches.
Author: Jacob Champion <jacob.champion@enterprisedb.com>
Reviewed-by: Mark Dilger <mark.dilger@enterprisedb.com>
Reviewed-by: solai v <solai.cdac@gmail.com>
Reported-by: Lars Kanis <lars@greiz-reinsdorf.de>
Discussion: https://postgr.es/m/2039ac58-d3e0-434b-ac1a-2a987f3b4cb1%40greiz-reinsdorf.de
Backpatch-through: 14
Commit dcb0049 accidentally changed the final expanded query's condition to > 2 while rewriting the example into SQL operator notation. The original query and the preceding rewritten forms all use >= 2, and view expansion should preserve that qualification. This commit changes the final condition from > 2 to >= 2. Backpatch to all supported versions. Reported-by: Yaroslav Saburov <y.saburov@gmail.com> Author: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Discussion: https://postgr.es/m/178248467618.108999.9966122434342474006@wrigleys.postgresql.org Backpatch-through: 14
Commit aa606b9 disallowed generated columns in COPY FROM WHERE expressions, and commit 21c69dc disallowed system columns. However, the COPY reference page still mentions only the restriction on subqueries. Update the documentation to also list generated columns and system columns as unsupported in COPY FROM WHERE expressions. Backpatch the generated-column documentation change to all supported versions. Backpatch the system-column documentation change to v19, where that restriction was introduced. Author: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com> Discussion: https://postgr.es/m/CAHGQGwEgxErc54yVOAVWCsr1O=8pgw4oKRPuEQ9mfhkoYGR_XA@mail.gmail.com Backpatch-through: 14
When compiling against OpenSSL, the <limits.h> header is indirectly included via openssl/ossl_typ.h from openssl/conf.h, but the LibreSSL version of ossl_typ.h does not include <limits.h> which cause compiler failure due to missing symbol (since ffd080d). Fix by explicitly including <limits.h>. Author: Daniel Gustafsson <dgustafsson@postgresql.org> Discussion: https://www.postgresql.org/message-id/6A9E7815-BD5A-4C31-A515-48159823406B@yesql.se Backpatch-through: 14
Check explicitly for pqsecure_read() returning an error. It shouldn't fail, and we would've caught it in the check for a short read, but better to be explicit so that the error message is more informative. We also shouldn't update 'inEnd' when the read fails, although that too is just pro forma as we will bail out and close the connection on error. Reported-by: Peter Eisentraut <peter@eisentraut.org> Discussion: https://www.postgresql.org/message-id/34844e8c-267c-4daf-b1e0-f26059a4a7d3@eisentraut.org Backpatch-through: 14
The pg_attribute_always_inline macro name is so long it forces pgindent to format the code in strange ways. Which may incentivize patch authors to either structure the code in strange ways (e.g. reorder prototypes), use shorter names, etc. Neither is very desirable for code readability. This shortens the name by removing the _attribute_ part. It also makes it more consistent with pg_noinline, which does not have the _attribute_ part either. Backpatched to all supported branches, to prevent conflicts when backpatching other fixes. The backbranches however keep both the old and new macro name, so that existing code keeps working. Author: Andres Freund <andres@anarazel.de> Reviewed-by: Peter Geoghegan <pg@bowt.ie> Reviewed-by: Tomas Vondra <tomas@vondra.me> Discussion: https://postgr.es/m/bqqdehahpoa36igpictuqyn2s2mexk3t3ehidh2ffd2slb35e5@rzgksuiszgbg Backpatch-through: 14
equalPolicy() is used in the relation cache to check if two policy definitions are equivalent, but missed to check for polpermissive. ALTER POLICY cannot switch a policy to be PERMISSIVE or RESTRICTIVE, so this would need a dropped and then re-created policy, which would trigger a relcache invalidation. Anyway, there is no harm in being consistent in the check, and if one decides to add an ALTER POLICY to switch PERMISSIVE or RESTRICTIVE, we would be silently in trouble. Author: Andreas Lind <andreaslindpetersen@gmail.com> Reviewed-by: Laurenz Albe <laurenz.albe@cybertec.at> Discussion: https://postgr.es/m/CAMxA3rv1CS6R7JR5ojz-3CmCEnZEFrqu+XXTnGbLRWrjJRH7sA@mail.gmail.com Backpatch-through: 14
…statement The documentation for log_parameter_max_length said it affects messages generated by log_duration. However, log_duration alone does not log bind parameter values, so this is misleading. This commit updates the documentation to reference log_min_duration_statement, which can log bind parameters, to better reflect actual behavior. Backpatch to all supported versions. Author: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Surya Poondla <suryapoondla4@gmail.com> Discussion: https://postgr.es/m/CAHGQGwGnCVMVz8-LU9F8Sh57bkQX3jMZzx7age7M0LFEz5=Fog@mail.gmail.com Backpatch-through: 14
Previously, libpqrcv_create_slot() checked only that CREATE_REPLICATION_SLOT returned PGRES_TUPLES_OK before reading values from the first row. If the server unexpectedly returned an invalid result, such as zero rows, PQgetvalue() could return NULL, leading to a crash while parsing the LSN. Other replication commands, such as IDENTIFY_SYSTEM, already validate the response shape before accessing result values, but CREATE_REPLICATION_SLOT did not. Fix this by verifying that CREATE_REPLICATION_SLOT response contains exactly one row with four fields, and report a protocol violation otherwise. Backpatch to all supported versions. Bug: #19547 Reported-by: Yuelin Wang <1217816127@qq.com> Author: Kenny Chen <kennychen851228@gmail.com> Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/19547-f7986f668f71e788@postgresql.org Discussion: https://postgr.es/m/CAPXstDtW2iqe+DJAOTQTX+rRziJp2UhZSo1+HRj1COAtbu+nKw@mail.gmail.com Backpatch-through: 14
We don't normally push down join quals into subqueries, because that would require creating parameterized plans. However, if the plan is already parameterized because it's LATERAL, we might as well push down any additional join quals, that refer the same relations that are already referenced within the subquery. This changes the behavior of the sublevels_up parameters to ReplaceVarsFromTargetList(). The targetlist entries used to replace vars are no longer offset by that amount. I'm not sure what the original thinking on it was, but all the existing callers passed sublevels_up = 0, so I hope this is OK.. XXX: fixes by reshke
Plan subqueries a second time, to create parameterized plans with join quals. XXX: fixes by reshke
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
16 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.