postgresql.git/src/backend, branch master

Change GEQO fitness comparisons to consider disabled_nodes.

2026-09-17T13:28:31Z

Prior to v18, the total cost of a plan was just one number, a floating-point value. Commit e22253467942fdb100087787c3e1e3a8620c54b2 introduced a second component, the number of disabled_nodes at or below that level of the plan tree. Unfortunately, I (rhaas) failed to realize that GEQO extracts the cost from each candidate plan and compares it directly as a measure of fitness. This means that, at least in principle, it's possible for GEQO to prefer a plan with more disabled_nodes and lower cost over one with fewer disabled_nodes and higher cost, which is incorrect. It may be possible for that to become a practical issue in v18, but it's much more likely to become an issue in v19 due to pg_plan_advice. Hence, since the straightforward fix breaks ABI compatibility, back-patch only to v19. Backpatch-through: 19 Discussion: https://postgr.es/m/CA+TgmoYmXy-jiP5qDhqNEiYFEBzQsArO6O2d9E8szNZqi1bePQ@mail.gmail.com

Fix postmaster crash on whitespace-only oauth_validator_libraries

2026-09-17T12:52:30Z

The check_oauth_validator check for an empty validator list didn't test for a string with only whitespace, which would cause the postmaster to crash. Instead of testing for the empty string cases, pass the config value to SplitDirectoriesString unconditionally. If an empty list is returned then the input string was empty. Since pstrdup cannot handle NULL, assert that the string ie set. While users cannot set the string to NULL, it is initialized to NULL so guard against programmer error. Check the parsed list instead. Assert that the GUC string is non-NULL before pstrdup(); users cannot set it to NULL, but the C variable is initialized that way. This also adds a TAP test that reloads a whitespace-only setting after pg_hba_file_rules and waits until the existing backend sees the restored GUC. Author: Grigorev Jurij Reviewed-by: Jacob Champion Reviewed-by: Daniel Gustafsson Discussion: https://postgr.es/m/04fa84f6ebbe400f940e179ebe1070e9@localhost.localdomain Backpatch-through: 18

Have the REPACK decoding worker use timeout values from the steering backend

2026-09-17T10:46:43Z

The worker connects as the table owner in a new session, so a role- or database-level lock_timeout and transaction_timeout unhelpfully apply to it, possibly canceling the wait for older transactions. This cannot be overridden by the REPACK calling session. Fix by passing the timeout values from the steering backend via the DecodingWorkerShared struct and adopting these values in the worker; this way, values from session-local SET reach the worker too. In passing, remove a pointless member from the same struct. Author: Shihao Zhong Backpatch-through: 19 Discussion: https://postgr.es/m/CAGRkXqTYaBjFvjtjPb1+=sZWvt93=2c472bmM+xdG7w9ZvAydA@mail.gmail.com

Tolerate partial pgstats entries in pgstat_gc_entry_refs()

2026-09-17T10:25:12Z

pgstat_get_entry_ref_cached() inserts a local entry_ref with shmem-related fields set to NULL, expecting pgstat_get_entry_ref() (its sole caller) to fill them up before returning. If an ERROR happens while pgstat_get_entry_ref() runs, it could be possible to finish with a local pgstats entry partially filled. This could lead to a crash of pgstat_gc_entry_refs(), which tolerates a NULL shared_stats in an assertion but unconditionally dereferenced its "dropped" and "generation" fields. This extends 4069df21beb8, being a cheap insurance against NULL pointer dereference, if some code paths of pgstat_get_entry_ref() are not able to perform any cleanup actions (for example after a dsm_create() throwing an ERROR). Reviewed-by: Grigorev Jurij Discussion: https://postgr.es/m/aqtiKTvl519bu8-V@paquier.xyz Backpatch-through: 15

Fix REPACK worker startup and shutdown sequences

2026-09-17T09:44:57Z

A REPACK background worker can fail to start for various reasons, but the REPACK steering process was not handling them correctly. For instance, the steering process waits on a condition variable, but it would simply hang if the worker doesn't send the signal. (A signal would be sent by postmaster, but it would wake up the process only to be ignored and continue sleeping.) Fix this by splitting the wait in two: first wait for the worker to attach to the error queue, and then wait on the condition variable as before. The shutdown sequence can also get stuck, if the message queue gets full while trying to shut down (this can apparently happen if the log level is set to very noisy). Previously the worker would send a signal and then detach; but the steering process can receive that signal, act on it, then fail to wake up to handle the detach, sleeping indefinitely. Fix this by having the worker send a Terminate message, which the steering process can react to. Author: Bharath Rupireddy Author: Shihao Zhong Author: Álvaro Herrera Reviewed-by: Antonin Houska Reviewed-by: Masahiko Sawada Reviewed-by: Shihao Zhong Reported-by: Nathan Bossart Reported-by: Bharath Rupireddy Reported-by: Nikolay Samokhvalov Backpatch-through: 19 Discussion: https://postgr.es/m/CALj2ACVAxA9HxvFe8HSspTJ-UO4Aoz%3DkuQdZBeLrod0gqUxH3g%40mail.gmail.com Discussion: https://postgr.es/m/apBpOVZOyqrakEr_@nathan

Fix typos and grammar of some comments

2026-09-17T07:50:44Z

These errors have been reported to the mailing lists in the last few weeks. Some of the spots fixed have been noticed by myself during independent code reviews, but not all.

Fix assertion after aborting internal subtransaction at transaction end

2026-09-17T05:24:22Z

Previously, aborting an internal subtransaction during COMMIT or PREPARE TRANSACTION could cause the following assertion failure. This could happen, for example, when a deferred constraint trigger fired at COMMIT and its PL/pgSQL exception block caught an error raised while executing the trigger function. TRAP: failed Assert("s->blockState == TBLOCK_SUBINPROGRESS || s->blockState == TBLOCK_INPROGRESS || s->blockState == TBLOCK_IMPLICIT_INPROGRESS || s->blockState == TBLOCK_PARALLEL_INPROGRESS || s->blockState == TBLOCK_STARTED"), File: "xact.c", Line: 4851, PID: 73455 An internal subtransaction should be able to be aborted while the parent transaction is in the COMMIT or PREPARE TRANSACTION phase. However, RollbackAndReleaseCurrentSubTransaction()'s assertion check previously did not allow TBLOCK_END and TBLOCK_PREPARE as parent transaction states, causing the assertion failure. This commit fixes the assertion check by allowing those two parent transaction states. Backpatch to all supported versions. Reported-by: Fabrízio de Royes Mello Author: Patrick Reynolds Reviewed-by: Fujii Masao Reviewed-by: Chao Li Reviewed-by: Fabrízio de Royes Mello Discussion: https://postgr.es/m/CABo-N97AeMbWuYTWg-3%3D2DkTR3EkvS%2BFt%3DyEaWB181STsR1mBg%40mail.gmail.com Backpatch-through: 14

Distinguish publication exclusions in object addresses.

2026-09-17T03:44:21Z

A pg_publication_rel entry can represent either an explicitly published relation or a table excluded from a FOR ALL TABLES publication, but the object address code treated every entry as a published relation without checking prexcept. EXCEPT entries thus appeared as ordinary published-table mappings in dependency messages, pg_identify_object(), and pg_identify_object_as_address(). Report such entries as "publication excluded relation" instead, with object identities indicating that the table is excluded from the publication. pg_get_object_address() also accepts this new object type, so that the output of pg_identify_object_as_address() can still be passed back to it to look up the same object. "publication relation" now resolves only non-EXCEPT entries, and "publication excluded relation" only EXCEPT entries. Oversight in commit fd366065e06. Author: Fujii Masao Author: Vignesh C Reviewed-by: shveta malik Reviewed-by: Peter Smith Reviewed-by: Zhijie Hou Reviewed-by: Nisha Moond Reviewed-by: Amit Kapila Reviewed-by: Chao Li Reviewed-by: Manuel Reyes Bravo Discussion: https://postgr.es/m/CAHGQGwHfESBexa7fq99EvFCf31av=O9h9udnw22ymxmm6LMZzw@mail.gmail.com Backpatch-through: 19, where it was introduced

Fix multixact members truncation at page boundary

2026-09-16T11:52:12Z

Like in PerformOffsetsTruncation() and e.g. in TruncateSUBTRANS(), need to step back to previous page at page boundary, to avoid passing a cutoff page to SimpleLruTruncate() that hasn't been created yet. Otherwise you can get a bogus 'LOG: could not truncate directory "pg_multixact/members": apparent wraparound' message in the log. Reported-by: Noah Misch Discussion: https://www.postgresql.org/message-id/20260827231757.78.noahmisch@microsoft.com Backpatch-through: 19

Say in the FSM README why its hint writes still need full page images

2026-09-16T10:49:59Z

The Recovery section said we would "operate correctly without the full page images that MarkBufferDirtyHint() provides", offering them only as a way to lose less slot knowledge to RBM_ZERO_ON_ERROR. That is true of freespace.c, which passes RBM_ZERO_ON_ERROR on every read, and false of the system around it, which reads the same files and does verify checksums. Reading it as a licence to dirty FSM pages without a full page image is what led to c06d1a4ba6b, since reverted. Say instead that RBM_ZERO_ON_ERROR is a property of this directory rather than of the fork, and name the readers that do not share it: RelationCopyStorage(), RelationCopyStorageUsingBuffer(), base backups and pg_checksums. Rather than presenting today's behavior as the only one possible, note that the alternative is for all of that code to skip checksum validation of the FSM. Reported-by: Noah Misch Reviewed-by: Noah Misch Reviewed-by: Andrey Borodin Discussion: https://postgr.es/m/20260901211837.f6.noahmisch%40microsoft.com