62389 Commits (cc0819e78ae321fd01bb40751be1f765b3932aaa)

 

All Branches   

Search

Author	SHA1	Message	Date
Richard Guo	cc0819e78a	Fix wrong unsafe-flag test in check_output_expressions() ... The check for window functions (point 4) guarded on the wrong bit: it tested UNSAFE_NOTIN_DISTINCTON_CLAUSE while setting UNSAFE_NOTIN_PARTITIONBY_CLAUSE. Each check in this loop guards on the same bit it is about to set, as an idempotency optimization, since unsafeFlags[] is accumulated across the arms of a set operation and there is no point recomputing a column's status once its bit is present. This is not a live bug. When UNSAFE_NOTIN_PARTITIONBY_CLAUSE is already set but UNSAFE_NOTIN_DISTINCTON_CLAUSE is not, the guard fails to skip targetIsInAllPartitionLists() and recomputes it, but setting the same bit again changes nothing. When UNSAFE_NOTIN_DISTINCTON_CLAUSE is already set, point 4 is skipped and UNSAFE_NOTIN_PARTITIONBY_CLAUSE is left unset; but such a column is already unsafe for pushdown via UNSAFE_NOTIN_DISTINCTON_CLAUSE, so the outcome is unchanged. To fix, test UNSAFE_NOTIN_PARTITIONBY_CLAUSE, matching the bit being set and the pattern of the surrounding checks. Back-patch to v15, where the buggy check was introduced. Author: Richard Guo <guofenglinux@gmail.com> Reviewed-by: Tender Wang <tndrwang@gmail.com> Reviewed-by: David Rowley <dgrowleyml@gmail.com> Discussion: https://postgr.es/m/CAMbWs49Q_xnF_P2QSUyDzJ34MnrO7dh-cUAaK2HJPgSgh88NcA@mail.gmail.com Backpatch-through: 15	6 days ago
Michael Paquier	1e9bc4074b	psql: Fix issues with deferred errors in pipelines ... When an error is raised while processing a Sync message in a pipeline, like a deferred constraint violation, the error was not associated with the piped command and was not counted in available_results. This caused assertion failures in discardAbortedPipelineResults(), keeping an incorrect state at pipeline exit, because the code assumed that the number of available and requested results would always be positive, expecting all the counters to be 0 at the end of a pipeline. This commit switches discardAbortedPipelineResults() and ExecQueryAndProcessResults() to take a softer approach when consuming and draining the results after an error. If there are still piped syncs in the pipeline when it ends, we now attempt to consume them before leaving the pipeline mode. Alexander has been able to reach two assertion failures through his testing. While investigating more this issue, I have bumped into two more. Most of these cases are covered by the regression tests added in this commit, plus some cases with mixes of pipelines, deferred errors and results fetched. Some of the tests discussed (like the backend termination one) could not be included in this commit but have been tested manually. Another test scenario discussed involved the injection of an error state in the backend, that was able to trick libpq internally and put its queue out of sync. This scenario is not going to happen in practice, but if we were to do something about it we would need to make libpq understand that it needs to fail in some cases but not block. Reported-by: Alexander Lakhin <exclusion@gmail.com> Author: Michael Paquier <michael@paquier.xyz> Discussion: https://postgr.es/m/19494-97a86d84fee71c47@postgresql.org Backpatch-through: 18	6 days ago
Jacob Champion	380a8b2ea0	doc: Correct the timeline for OAuth's shutdown_cb ... During original feature development, the OAuth validator shutdown callback was invoked via before_shmem_exit(). That was changed to use a reset callback before commit, but I forgot to update the documentation for validator developers. Correct this and backport to 18, where OAuth was introduced. The callback is invoked whenever the server is "finished" with token validation. (We make no stronger guarantees here, in the hopes that this API might successfully navigate future multifactor authentication support and/or changes to the server threading model.) Reported-by: Zsolt Parragi <zsolt.parragi@percona.com> Reviewed-by: Zsolt Parragi <zsolt.parragi@percona.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Discussion: https://postgr.es/m/CAN4CZFOuMb_gnLvCwRdMybg_k8WRNJTjcij%2BPoQkuQHDUzxGWg%40mail.gmail.com Backpatch-through: 18	1 week ago
Heikki Linnakangas	c8b4186d6e	Use term "referenced" rather than "dependent" in dependency locking ... 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	2 weeks ago
Andres Freund	c0bf1d89df	Make stack depth check work with asan's use-after-return ... 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 de447bb8e6, 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	2 weeks ago
Fujii Masao	e5d019fbdc	postgres_fdw, dblink: Validate use_scram_passthrough values ... The use_scram_passthrough option in postgres_fdw and dblink accepts only boolean values. However, unlike other boolean options such as keep_connections, its value was not previously validated. As a result, commands such as "CREATE SERVER ... OPTIONS (use_scram_passthrough 'invalid')" could succeed unexpectedly. This commit updates postgres_fdw and dblink to validate that use_scram_passthrough is assigned a valid boolean value, and throw an error for invalid input. Backpatch to v18, where use_scram_passthrough was introduced. Author: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com> Reviewed-by: Matheus Alcantara <matheusssilv97@gmail.com> Discussion: https://postgr.es/m/CAHGQGwF+-k-Ehsu5W94ZP7GxS3wiBd+mi0PfGTdJ_i2Yr0zR3g@mail.gmail.com Backpatch-through: 18	2 weeks ago
Masahiko Sawada	1a9b1cc18e	Fix race between ProcSignalInit() and EmitProcSignalBarrier(). ... Previously, ProcSignalInit() read the global barrier generation before publishing its PID into pss_pid. This created a race condition: a process could initialize its local generation with an older global value, while a concurrent EmitProcSignalBarrier() might skip that process because its pss_pid was still zero. This resulted in WaitForProcSignalBarrier() hanging indefinitely. Fix this by publishing pss_pid before reading psh_barrierGeneration with a memory barrier so that the store to pss_pid is ordered before the load. A concurrent EmitProcSignalBarrier() then either observes the published PID and signals this slot, or completes its generation increment before we load it. While this race has become more visible due to recent features using signal barriers in more places (such as online wal_level changes), the issue is theoretically present since signal barriers were introduced to release smgr caches (e.g., in DROP DATABASE). v14 has the procsiangl barrier infrastricutre but no in-tree caller that actually emits a barrier, so the case is unreachable there. This issue was also reported by buildfarm member flaviventris. Reported-by: Melanie Plageman <melanieplageman@gmail.com> Reviewed-by: Alexander Lakhin <exclusion@gmail.com> Reviewed-by: Matthias van de Meent <boekewurm+postgres@gmail.com> Discussion: https://postgr.es/m/CAEze2WgAJmWReDN7Chtba8Er2YBvKCoa0KVN25-1evnTrHsLyA@mail.gmail.com Backpatch-through: 15	2 weeks ago
Heikki Linnakangas	c8cd3d6976	Avoid orphaned objects dependencies ... 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	2 weeks ago
Heikki Linnakangas	f9d5a52da4	Don't try to record dependency on a dropped column's datatype ... 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 713bce9484. 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	2 weeks ago
Michael Paquier	12c9b8b422	Fix procLatch ownership race in ProcKill() ... 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	2 weeks ago
Michael Paquier	ae08eb1687	Fix race conditions in ProcKill()'s lock-group freelist handling ... 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	2 weeks ago
Fujii Masao	196b4b5ae6	pg_createsubscriber: Fix cleanup of publisher-side objects after errors ... When pg_createsubscriber fails after creating logical replication objects, it should remove the publication and replication slot that it created on the publisher. Previously, if dropping subscriber-side objects failed, pg_createsubscriber reset its internal cleanup state too early. As a result, the exit-time cleanup could skip removing the publication or replication slot on the publisher. This could leave pg_createsubscriber-created objects behind on the publisher after a failed run. That can make a retry harder, because the leftover publication or replication slot may need to be removed manually before running pg_createsubscriber again. In the case of a replication slot, leaving it behind can also retain WAL files longer than expected. The cause of this issue was that the flags made_publication and made_replslot tracking whether pg_createsubscriber created a publication or replication slot on the primary were incorrectly reset to false when failures occurred while dropping objects on the subscriber. This commit fixes the issue by preventing those cleanup flags from being reset even when failures occurred while dropping objects on the subscriber, ensuring proper cleanup of primary objects before exit on failure. Backpatch to v17, where pg_createsubscriber was added. Author: Nisha Moond <nisha.moond412@gmail.com> Reviewed-by: David G. Johnston <david.g.johnston@gmail.com> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Peter Smith <smithpb2250@gmail.com> Discussion: https://postgr.es/m/CABdArM5V9QKK1PkLY9dpgAcZa3kUp84-wPqPovxvdLOri4=69w@mail.gmail.com Backpatch-through: 17	2 weeks ago
Alexander Korotkov	97b5c5aaad	Skip pg_database.dathasloginevt cleanup on standby ... EventTriggerOnLogin() tries to clear pg_database.dathasloginevt when the database no longer has any login event triggers but the flag is still set. To make that safe against concurrent flag setters, it takes a conditional AccessExclusiveLock on the database object. On a hot standby, that lock acquisition fails outright with FATAL: cannot acquire lock mode AccessExclusiveLock on database objects while recovery is in progress because LockAcquireExtended() refuses locks stronger than RowExclusiveLock on database objects during recovery. The standby already replays the flag's value from the primary, so the dangling flag is the result of replaying a state in which the primary had already dropped its login event triggers but not yet run a login event trigger pass to clear the flag. Any session connecting to the standby in that window therefore fails to connect. Skip the cleanup on a standby. The flag will be cleared via WAL replay once the primary clears it on its side. Add a recovery TAP test that reproduces the original report: create and drop a login event trigger on the primary in one session, wait for the standby to replay, then verify that a fresh connection to the standby succeeds. Backpatch to v17, where the login event triggers were introduced. Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com> Reported-by: Egor Chindyaskin <kyzevan23@mail.ru> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Discussion: https://postgr.es/m/19488-d7ccfca2bf6b74b0%40postgresql.org Backpatch-through: 17	2 weeks ago
Tom Lane	0480d84ee3	Add stack depth check to QueueFKConstraintValidation(). ... QueueFKConstraintValidation() recurses through the partition hierarchy to queue child constraint validations and to mark child rows as validated. With a sufficiently deep partition tree, this can result in a stack-overflow crash. Defend against that as we do elsewhere. Bug: #19482 Reported-by: Alexander Lakhin <exclusion@gmail.com> Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/19482-4cc37cbf52d55235@postgresql.org Backpatch-through: 18	2 weeks ago
Tom Lane	e7544c518a	Fix missed ReleaseVariableStats() in intarray's _int_matchsel(). ... 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 c6fbe6d6f. 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	2 weeks ago
Fujii Masao	cd777e27e2	dblink: Reject use_scram_passthrough on foreign-data wrappers ... Previously, dblink accepted the use_scram_passthrough option on foreign-data wrappers via ALTER FOREIGN DATA WRAPPER dblink_fdw OPTIONS, even though the setting had no effect there. use_scram_passthrough should be only meaningful for foreign servers and user mappings, so this commit updates dblink to accept the option only in those contexts. Backpatch to v18, where use_scram_passthrough was introduced. Author: Matheus Alcantara <matheusssilv97@gmail.com> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/CAHGQGwEJ8rZjmbOvCicyr4vbuLio082bNTde0WNoSWaWr9wVcg@mail.gmail.com Backpatch-through: 18	2 weeks ago
Fujii Masao	130396e6c0	dblink: Give user mapping precedence for use_scram_passthrough ... Commit 97f6fc10ff changed postgres_fdw so that user-mapping settings override foreign server settings for use_scram_passthrough. This commit applies the same behavior to dblink. Backpatch to v18, where use_scram_passthrough was introduced. Author: Matheus Alcantara <matheusssilv97@gmail.com> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/CAHGQGwEJ8rZjmbOvCicyr4vbuLio082bNTde0WNoSWaWr9wVcg@mail.gmail.com Backpatch-through: 18	2 weeks ago
Fujii Masao	88d7748d2a	postgres_fdw: Give user mapping precedence for use_scram_passthrough ... Previously, when use_scram_passthrough was specified on both a foreign server and a user mapping, the server-level setting took precedence over the user-mapping setting. This was inconsistent with the usual semantics of postgres_fdw options, where foreign server options provide shared defaults and user mapping options override them on a per-user basis. This commit updates postgres_fdw so that the user-mapping setting takes precedence when use_scram_passthrough is specified in both places. This matches the behavior of other connection options such as sslcert and sslkey. Backpatch to v18, where use_scram_passthrough was introduced. In v18, this only affects limited configurations that specify conflicting values at both the foreign server and user-mapping levels. In such cases, users would naturally expect the user-mapping setting to override the server-level setting, so changing the behavior should be minimally disruptive. Also keeping v18 as the only branch with different semantics for use_scram_passthrough would be unnecessarily confusing, so backpatch this fix to v18. Author: Matheus Alcantara <matheusssilv97@gmail.com> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/CAHGQGwEJ8rZjmbOvCicyr4vbuLio082bNTde0WNoSWaWr9wVcg@mail.gmail.com Backpatch-through: 18	2 weeks ago
Michael Paquier	b5fd5723a6	Fix size check in statext_dependencies_deserialize() ... 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 d08c44f7a4. Author: Ilia Evdokimov <ilya.evdokimov@tantorlabs.com> Discussion: https://postgr.es/m/4b8d299d-2505-4c30-bf80-0f697410db35@tantorlabs.com Backpatch-through: 14	2 weeks ago
Michael Paquier	b903d17927	Avoid exposing WAL receiver raw conninfo during timeline jumps ... 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	2 weeks ago
Fujii Masao	41247cdf69	Prevent setting NO INHERIT on partitioned NOT NULL constraints ... The documentation states that NOT NULL constraints on partitioned tables are always inherited by all partitions, and therefore cannot be declared NO INHERIT. While a check already existed to reject creating such constraints with NO INHERIT, previously the same check was missing for ALTER TABLE ... ALTER CONSTRAINT ... NO INHERIT. This commit adds the missing check so that attempting to set NO INHERIT on a partitioned NOT NULL constraint now fails. Backpatch to v18, where ALTER TABLE ... ALTER CONSTRAINT ... [NO] INHERIT was added. Author: Andreas Karlsson <andreas@proxel.se> Reviewed-by: Jim Jones <jim.jones@uni-muenster.de> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/ecc985ad-6ec1-4094-a315-317943ca5f3f@proxel.se Backpatch-through: 18	2 weeks ago
Fujii Masao	89b4b3ae35	pg_recvlogical: Honor source cluster file permissions for output files ... Commit c37b3d08ca 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	3 weeks ago
Daniel Gustafsson	e0c641ebbf	psql: Make ParseVariableDouble reject values above max ... ParseVariableDouble missed returning false after logging an error when the parsed value exceeded max, making the value assigned rather than rejected. Backpatch down to v18 where this was introduced as part of the \WATCH_INTERVAL. Author: Sven Klemm <sven@tigerdata.com> Co-authored-by: Daniel Gustafsson <daniel@yesql.se> Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Discussion: https://postgr.es/m/CAMCrgp31p_5SDVi7dwnP39tTW5icQ0MWHA+N4kJdXgkL0PEy8w@mail.gmail.com Backpatch-through: 18	3 weeks ago
Michael Paquier	20a4b06a1e	injection_points: Move some structs to new header injection_points.h ... This commit moves the definitions of InjectionPointConditionType and InjectionPointCondition into a new header local to the test module injection_points.h, so as these can be shared across more files in the module. A patch for a bug fix is under discussion, whose proposed test will benefit from this refactoring. Backpatch down to where the module exists, as this should be useful for future bug fixes, even cases unrelated to the thread where this change has been discussed. Author: Andrey Borodin <x4mmm@yandex-team.ru> Author: Vlad Lesin <vladlesin@gmail.com> Discussion: https://postgr.es/m/d2983796-2603-41b7-a66e-fc8489ddb954@gmail.com Backpatch-through: 17	3 weeks ago
Noah Misch	dc3db3a834	Use ereport(ERROR), not Assert(), for publisher tuples missing columns. ... 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	3 weeks ago
Tom Lane	d472bf14f2	Doc: fix release-note typo. ... 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	3 weeks ago
Michael Paquier	f45f418275	Re-add regression tests for ltree and intarray ... These tests have been removed by 906ea101d0, 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	3 weeks ago
Nathan Bossart	ed0c4d5af2	refint: Fix segfault in check_foreign_key(). ... 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 260e97733b. 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	4 weeks ago
Alexander Korotkov	1b0dd08157	Prevent access to other sessions' temp tables ... Commit b7b0f3f272 ("Use streaming I/O in sequential scans") routed sequential scans through read_stream_next_buffer(), bypassing the RELATION_IS_OTHER_TEMP() check in ReadBufferExtended(). As a result, a superuser can attempt to read or modify temp tables of other sessions through the read-stream path. When the query plan uses no index, SELECT/UPDATE/DELETE/MERGE silently see no rows / report zero affected rows, and COPY produces an empty output -- because the buffer manager has no visibility into the owning session's local buffers and silently returns nothing. Any query plan that uses, for instance, a btree index still errors out via the existing check in ReadBufferExtended(), which is reached from hio.c and nbtree respectively, but this is incidental. Fix by enforcing RELATION_IS_OTHER_TEMP() at the three additional buffer-manager entry points: - read_stream_begin_impl() rejects the read at stream setup time, covering sequential and bitmap scans that go through the read-stream path. - ReadBuffer_common() becomes the canonical place for the check, consolidating the existing one previously kept in ReadBufferExtended(). All ReadBufferExtended() callers go through ReadBuffer_common(), so the consolidation is behavior-preserving. - StartReadBuffersImpl() catches direct callers of StartReadBuffers() that bypass both of the above. This is currently defense-in-depth, but documents the contract for future code. The companion test in src/test/modules/test_misc was added in the preceding commit; this commit updates the assertions for SELECT, UPDATE, DELETE, MERGE, and COPY (which previously documented the bug as silent success) to expect the new error. Author: Jim Jones <jim.jones@uni-muenster.de> Author: Daniil Davydov <3danissimo@gmail.com> Co-authored-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Soumya S Murali <soumyamurali.work@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/CAJDiXghdFcZ8%3Dnh4G69te7iRr3Q0uFyXxb3ZdG09_GTNZXwH0g%40mail.gmail.com Backpatch-through: 17	4 weeks ago
Alexander Korotkov	1cd37a7a8d	Add tests for cross-session temp table access ... Add a TAP test in src/test/modules/test_misc that documents what happens when one session attempts to read or modify another session's temporary table. This commit only adds tests; it does not change backend behavior, so the assertions reflect current behavior: - SELECT, UPDATE, DELETE, MERGE, COPY on a table without an index silently succeed with no error and zero rows / zero affected rows. These commands run through the read-stream path, which currently bypasses the RELATION_IS_OTHER_TEMP() check. This is the underlying bug to be fixed in a follow-up. - INSERT errors with "cannot access temporary tables of other sessions" because hio.c calls ReadBufferExtended() to find a page with free space and is caught by the existing check there. - Index scan errors via the same existing check, reached through nbtree -> ReadBuffer -> ReadBufferExtended. - TRUNCATE / ALTER TABLE / ALTER INDEX / CLUSTER fail with their command-specific error messages. - VACUUM is silently skipped to avoid noise during database-wide VACUUM (vacuum_rel() returns without warning). - DROP TABLE is intentionally allowed: DROP does not touch the table's contents, and autovacuum relies on this to clean up temp relations orphaned by a crashed backend. - ALTER FUNCTION / DROP FUNCTION on an owner-created function over its own temp row type work as catalog operations -- they don't read the underlying data. - CREATE FUNCTION from a separate session, using another session's temp row type as an argument, is allowed but emits a NOTICE: the function is moved into the creator's pg_temp namespace with an auto-dependency on the borrowed type, so it disappears together with the session that created it. - A bare DROP TABLE on a temp table that has a cross-session dependent function fails with a catalog-level dependency error. - LOCK TABLE in ACCESS SHARE mode on another session's temp table succeeds and properly blocks the owner's session-exit cleanup (which acquires AccessExclusiveLock via findDependentObjects). This exercises the same LockRelationOid path used by autovacuum when cleaning up orphaned temp relations. - When the owner session ends, the normal session-exit cleanup cascades through DEPENDENCY_NORMAL and removes both the temp objects and any cross-session functions that depended on them. Also, document the contract for RELATION_IS_OTHER_TEMP() so that future buffer-access entry points enforce the same rule. Backpatch this through PostgreSQL 17, where b7b0f3f272 introduces a code path bypassing this check. Author: Jim Jones <jim.jones@uni-muenster.de> Author: Daniil Davydov <3danissimo@gmail.com> Co-authored-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Soumya S Murali <soumyamurali.work@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/CAJDiXghdFcZ8%3Dnh4G69te7iRr3Q0uFyXxb3ZdG09_GTNZXwH0g%40mail.gmail.com Backpatch-through: 17	4 weeks ago
Fujii Masao	98dd6c2046	pgbench: fix verbose error message corruption with multiple threads ... When pgbench runs with multiple threads and verbose error reporting is enabled (--verbose-errors), multiple clients can build verbose error messages concurrently. Previously, a function-local static PQExpBuffer was used for these messages, causing the buffer to be shared across threads. This was not thread-safe and could result in corrupted or incorrect log output. Fix this by using a local PQExpBufferData instead of a static buffer. This keeps verbose error messages correct during concurrent execution. Backpatch to v15, where this issue was introduced. Author: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Alex Guo <guo.alex.hengchen@gmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Discussion: https://postgr.es/m/CAHGQGwER1AjGXpkKB9t9820NBhMQ_Ghv7=HsKeodUr3=SZsF4g@mail.gmail.com Backpatch-through: 15	4 weeks ago
Michael Paquier	89192080f0	Add more tests for corrupted data with pglz_decompress() ... Two cases fixed by 2b5ba2a0a1 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 67d318e704. Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com> Discussion: https://postgr.es/m/agF4xkIdRcrCIprs@paquier.xyz Backpatch-through: 14	4 weeks ago
Fujii Masao	d9cd9b4d7e	Fix stale COPY progress during logical replication table sync ... 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	4 weeks ago
Tom Lane	f5cc81719e	Stamp 18.4.	4 weeks ago
Tom Lane	bbd12e8010	Last-minute updates for release notes. ... Security: CVE-2026-6472, CVE-2026-6473, CVE-2026-6474, CVE-2026-6475, CVE-2026-6476, CVE-2026-6477, CVE-2026-6478, CVE-2026-6479, CVE-2026-6575, CVE-2026-6637, CVE-2026-6638	4 weeks ago
Heikki Linnakangas	3fbec9e504	Use palloc_array() in a few more places to avoid overflow ... These could overflow on 32-bit systems. Backpatch-through: 14 Security: CVE-2026-6473	4 weeks ago
Tom Lane	05e73b5c35	Remove test cases for field overflows in intarray and ltree. ... These checks are failing in the buildfarm, reporting stack overflows rather than the expected errors, though seemingly only on ppc64 and s390x platforms. Perhaps there is something off about our tests for stack depth on those architectures? But there's no time to debug that right now, and surely these tests aren't too essential. Revert for now and plan to revisit after the release dust settles. Backpatch-through: 14 Security: CVE-2026-6473	4 weeks ago
Nathan Bossart	1ebda7da9a	refint: Fix SQL injection and buffer overruns. ... Maliciously crafted key value updates could achieve SQL injection within check_foreign_key(). To fix, ensure new key values are properly quoted and escaped in the internally generated SQL statements. While at it, avoid potential buffer overruns by replacing the stack buffers for internally generated SQL statements with StringInfo. Reported-by: Nikolay Samokhvalov <nik@postgres.ai> Author: Nathan Bossart <nathandbossart@gmail.com> Reviewed-by: Noah Misch <noah@leadboat.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Security: CVE-2026-6637 Backpatch-through: 14	4 weeks ago
Nathan Bossart	be01364404	Mark PQfn() unsafe and fix overrun in frontend LO interface. ... When result_is_int is set to 0, PQfn() cannot validate that the result fits in result_buf, so it will write data beyond the end of the buffer when the server returns more data than requested. Since this function is insecurable and obsolete, add a warning to the top of the pertinent documentation advising against its use. The only in-tree caller of PQfn() is the frontend large object interface. To fix that, add a buf_size parameter to pqFunctionCall3() that is used to protect against overruns, and use it in a private version of PQfn() that also accepts a buf_size parameter. Reported-by: Yu Kunpeng <yu443940816@live.com> Reported-by: Martin Heistermann <martin.heistermann@unibe.ch> Author: Nathan Bossart <nathandbossart@gmail.com> Reviewed-by: Noah Misch <noah@leadboat.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Etsuro Fujita <etsuro.fujita@gmail.com> Security: CVE-2026-6477 Backpatch-through: 14	4 weeks ago
Heikki Linnakangas	67dd6243dc	Fix integer overflow in array_agg(), when the array grows too large ... If you accumulate many arrays full of NULLs, you could overflow 'nitems', before reaching the MaxAllocSize limit on the allocations. Add an explicit check that the number of items doesn't grow too large. With more than MaxArraySize items, getting the final result with makeArrayResultArr() would fail anyway, so better to error out early. Reported-by: Xint Code Author: Heikki Linnakangas <heikki.linnakangas@iki.fi> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Backpatch-through: 14 Security: CVE-2026-6473	4 weeks ago
Tom Lane	dd8af778d2	Fix integer-overflow and alignment hazards in locale-related code. ... pg_locale_icu.c was full of places where a very long input string could cause integer overflow while calculating a buffer size, leading to buffer overruns. It also was cavalier about using char-type local arrays as buffers holding arrays of UChar. The alignment of a char[] variable isn't guaranteed, so that this risked failure on alignment-picky platforms. The lack of complaints suggests that such platforms are very rare nowadays; but it's likely that we are paying a performance price on rather more platforms. Declare those arrays as UChar[] instead, keeping their physical size the same. pg_locale_libc.c's strncoll_libc_win32_utf8() also had the disease of assuming it could double or quadruple the input string length without concern for overflow. Reported-by: Xint Code Reported-by: Pavel Kohout <pavel.kohout@aisle.com> Author: Tom Lane <tgl@sss.pgh.pa.us> Backpatch-through: 14 Security: CVE-2026-6473	4 weeks ago
Michael Paquier	6a67c540a6	Prevent path traversal in pg_basebackup and pg_rewind ... pg_rewind and pg_basebackup could be fed paths from rogue endpoints that could overwrite the contents of the client when received, achieving path traversal. There were two areas in the tree that were sensitive to this problem: - pg_basebackup, through the astreamer code, where no validation was performed before building an output path when streaming tar data. This is an issue in v15 and newer versions. - pg_rewind file operations for paths received through libpq, for all the stable branches supported. In order to address this problem, this commit adds a helper function in path.c, that reuses path_is_relative_and_below_cwd() after applying canonicalize_path(). This can be used to validate the paths received from a connection point. A path is considered invalid if any of the two following conditions is satisfied: - The path is absolute. - The path includes a direct parent-directory reference. Reported-by: XlabAI Team of Tencent Xuanwu Lab Reported-by: Valery Gubanov <valerygubanov95@gmail.com> Author: Michael Paquier <michael@paquier.xyz> Reviewed-by: Amit Kapila <amit.kapila16@gmail.com> Backpatch-through: 14 Security: CVE-2026-6475	4 weeks ago
Nathan Bossart	55328e3a98	Avoid overflow in size calculations in formatting.c. ... A few functions in this file were incautious about multiplying a possibly large integer by a factor more than 1 and then using it as an allocation size. This is harmless on 64-bit systems where we'd compute a size exceeding MaxAllocSize and then fail, but on 32-bit systems we could overflow size_t, leading to an undersized allocation and buffer overrun. To fix, use palloc_array() or mul_size() instead of handwritten multiplication. Reported-by: Sven Klemm <sven@tigerdata.com> Reported-by: Xint Code Author: Nathan Bossart <nathandbossart@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Tatsuo Ishii <ishii@postgresql.org> Security: CVE-2026-6473 Backpatch-through: 14	4 weeks ago
Nathan Bossart	a44780f412	Check CREATE privilege on multirange type schema in CREATE TYPE. ... This omission allowed roles to create multirange types in any schema, potentially leading to privilege escalations. Note that when a multirange type name is not specified in CREATE TYPE, it is automatically placed in the range type's schema, which is checked at the beginning of DefineRange(). Reported-by: Jelte Fennema-Nio <postgres@jeltef.nl> Author: Jelte Fennema-Nio <postgres@jeltef.nl> Reviewed-by: Nathan Bossart <nathandbossart@gmail.com> Reviewed-by: Tomas Vondra <tomas@vondra.me> Security: CVE-2026-6472 Backpatch-through: 14	4 weeks ago
Nathan Bossart	c2e44c370e	pg_createsubscriber: Obstruct SQL injection via subscription names. ... drop_existing_subscription() neglected to escape the subscription name when generating its query string. To fix, use PQescapeIdentifier() to construct a properly escaped name, and use it in the ALTER SUBSCRIPTION and DROP SUBSCRIPTION commands. Reported-by: Yu Kunpeng <yu443940816@live.com> Author: Nathan Bossart <nathandbossart@gmail.com> Reviewed-by: Amit Kapila <amit.kapila16@gmail.com> Security: CVE-2026-6476 Backpatch-through: 17	4 weeks ago
Michael Paquier	661095c40c	Fix MCV input array checks in statistics restore functions ... The SQL functions for the restore of attribute and expression statistics accept "most_common_vals" and "most_common_freqs" as independent arrays. The planner assumes these have the same number of elements, but it was possible to insert in the catalogs data that would cause an over-read when the catalog data is loaded in the planner. There were two holes in the stats restore logic: - Both arrays should match in size. - The input array must be one-dimensional, and it should match with what is delivered by pg_dump when scanning the pg_stats catalogs. The multivariate extended statistics MCV path (import_mcv) already validated these inputs via check_mcvlist_array(), and is not affected. These problems exist in v18 and newer versions for the restore of attribute statistics. These problems affect only HEAD for the restore of the expression statistics. Reported-by: Jeroen Gui <jeroen.gui1@proton.me> Author: Michael Paquier <michael@paquier.xyz> Reviewed-by: Amit Langote <amitlangote09@gmail.com> Reviewed-by: John Naylor <johncnaylorls@gmail.com> Security: CVE-2026-6575 Backpatch-through: 18	4 weeks ago
Tom Lane	c6e7a9ef30	Guard against unsafe conditions in usage of pg_strftime(). ... Although pg_strftime() has defined error conditions, no callers bother to check for errors. This is problematic because the output string is very likely not null-terminated if an error occurs, so that blindly using it is unsafe. Rather than trusting that we can find and fix all the callers, let's alter the function's API spec slightly: make it guarantee a null-terminated result so long as maxsize > 0. Furthermore, if we do get an error, let's make that null-terminated result be an empty string. We could instead truncate at the buffer length, but that risks producing mis-encoded output if the tz_name string contains multibyte characters. It doesn't seem reasonable for src/timezone/ to make use of our encoding-aware truncation logic. Also, the only really likely source of a failure is a user-supplied timezone name that is intentionally trying to overrun our buffers. I don't feel a need to be particularly friendly about that case. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: John Naylor <johncnaylorls@gmail.com> Backpatch-through: 14 Security: CVE-2026-6474	4 weeks ago
Tom Lane	ba27389c2c	Avoid passing unintended format codes to snprintf(). ... timeofday() assumed that the output of pg_strftime() could not contain % signs, other than the one it explicitly asks for with %%. However, we don't have that guarantee with respect to the time zone name (%Z). A crafted time zone setting could abuse the subsequent snprintf() call, resulting in crashes or disclosure of server memory. To fix, split the pg_strftime() call into two and then treat the outputs as literal strings, not a snprintf format string. The extra pg_strftime() call doesn't really cost anything, since the bulk of the conversion work was done by pg_localtime(). Also, adjust buffer widths so that we're not risking string truncation during the snprintf() step, as that would create a hazard of producing mis-encoded output. This also fixes a latent portability issue: the format string expects an int, but tp.tv_usec is long int on many platforms. Reported-by: Xint Code Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: John Naylor <johncnaylorls@gmail.com> Backpatch-through: 14 Security: CVE-2026-6474	4 weeks ago
Noah Misch	cb35d73068	Fix SQL injection in logical replication origin checks. ... ALTER SUBSCRIPTION ... REFRESH PUBLICATION interpolates schema and relation names into SQL without quoting them. A crafted subscriber relation name can inject arbitrary SQL on the publisher. Test such a name. Back-patch to v16, where commit 8756930190 first appeared. Reported-by: Pavel Kohout <pavel.kohout@aisle.com> Author: Pavel Kohout <pavel.kohout@aisle.com> Reviewed-by: Nathan Bossart <nathandbossart@gmail.com> Backpatch-through: 16 Security: CVE-2026-6638	4 weeks ago
Michael Paquier	d93ef41317	Apply timingsafe_bcmp() in authentication paths ... This commit applies timingsafe_bcmp() to authentication paths that handle attributes or data previously compared with memcpy() or strcmp(), which are sensitive to timing attacks. The following data is concerned by this change, some being in the backend and some in the frontend: - For a SCRAM or MD5 password, the computed key or the MD5 hash compared with a password during a plain authentication. - For a SCRAM exchange, the stored key, the client's final nonce and the server nonce. - RADIUS (up to v18), the encrypted password. - For MD5 authentication, the MD5(MD5()) hash. Reported-by: Joe Conway <mail@joeconway.com> Security: CVE-2026-6478 Author: Michael Paquier <michael@paquier.xyz> Reviewed-by: John Naylor <johncnaylorls@gmail.com> Backpatch-through: 14	4 weeks ago