postgresql.git, branch REL_19_STABLE

Further post-revert cleanup after online checksums

2026-09-17T21:04:04Z

When reverting I had missed updating the documentation for tracking data checksum failures and the checksum version in the REDO record. The test- code for enabling and disabling checksums offline was originally kept to minimize backpatching conflicts, but the amount of testcode backpatching doesn't really warrant keeping dead code. Since no version has been shipped since bumping XLOG_PAGE_MAGIC it is left at the previous bump version. Reported-by: Fujii Masao Reported-by: Manuel Reyes Bravo Discussion: https://postgr.es/m/CAHGQGwFLNCA9nVHSsC_=G_mvsK_fAFb+QbJAL7=R9cK2PL9ZBQ@mail.gmail.com

pg_plan_advice: Fix defects in JOIN_ORDER advice feedback.

2026-09-17T15:26:46Z

This commit fixes several related problems. All of these problems escaped testing for the same reason: they do not occur when only generated advice is supplied, and therefore test_plan_advice was incapable of detecting these shortcomings. First, prior to this commit, the advice feedback code never regarded an unordered sublist of a JOIN_ORDER specification as matching an unrolled join. As a result, when JOIN_ORDER() advice contained unordered sublists, the advice feedback tended to be "matched, failed" even when the advice worked exactly as intended. Only the case where an unordered sublist was implemented by a plan shape not subject to unrolling, such as a partitionwise join, worked properly. Second, prior to this commit, a join order sublist in the initial position wasn't properly handled. Note that this overlaps with the problem described in the previous paragraph; JOIN_ORDER({a b} c) was broken both because of the unordered sublist and because of the sublist being in the initial position. However, there's more to this case: JOIN_ORDER((a b) c) means the same as JOIN_ORDER(a b c), but the advice feedback code didn't know that, and would generate "matched, failed" for the former case even when everything was working. Finally, prior to this commit, advice feedback didn't correctly handle single-element sublists. Those are pretty nonsensical, since by definition a join involves at least 2 tables, so we could just ban that case. Instead, at least for now, I've chosen to make advice feedback handle such cases in the same way that advice enforcement already does: the extra grouping levels are simply disregarded, so that JOIN_ORDER({a} ((b))) is enforced in the same way as, and also gets the same advice feedback as, JOIN_ORDER(a b). Reported-by: Noah Misch Backpatch-through: 19 Discussion: https://postgr.es/m/CA+TgmoYmXy-jiP5qDhqNEiYFEBzQsArO6O2d9E8szNZqi1bePQ@mail.gmail.com Reviewed-by: Ayush Tiwari

Change GEQO fitness comparisons to consider disabled_nodes.

2026-09-17T13:37:09Z

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:21Z

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

doc: Say which LSN gives read-your-writes with WAIT

2026-09-17T06:36:36Z

The reference page and the read-your-writes section both presented WAIT in standby_replay mode as enough for read-your-writes, without saying which LSN to wait for. Read as written, an LSN taken after the last statement but before COMMIT would do, and it would not: the standby position WAIT compares against is the end of the last replayed record, so a target that falls inside the COMMIT record is satisfied while that record is still unapplied. Say that the target must be at or after the end of the write transaction's COMMIT record, and note in the example that autocommit is what puts the UPDATE's commit before the call that reads the position. Author: Sami Imseih Reviewed-by: Xuneng Zhou Reviewed-by: Alexander Korotkov Discussion: https://postgr.es/m/CAN12%2BYKN7gXb1o9bDWgfA%3D6wjDrqNEgt%2BrXJiAWXgPCXQ5TqpA%40mail.gmail.com Backpatch-through: 19

doc: Explain when to use the WAIT NO_THROW option

2026-09-17T06:36:36Z

The description of NO_THROW covered what the option does but not when an application would want it. Explain that it suits callers that treat timeout or not in recovery as expected results to be handled as part of ordinary control flow, note the obligation to check the returned status, and give the reason to omit the option. Be precise about the option's scope: it changes only how those two wait outcomes are reported. Soften the description's claim that the command "returns a status string instead of throwing errors" accordingly, and say that invalid input still raises an error, as does any condition checked before the wait begins. Name two of those conditions as examples rather than listing them, since the set grows. Author: Rithvika Devisetti Reported-by: Peter Eisentraut Reviewed-by: Kiran Kaki Reviewed-by: Xuneng Zhou Reviewed-by: Satyanarayana Narlapuram Reviewed-by: Alexander Korotkov Discussion: https://postgr.es/m/14415b05-16d0-446f-ba7d-c891db8b3406%40eisentraut.org Backpatch-through: 19

Fix assertion after aborting internal subtransaction at transaction end

2026-09-17T05:25:09Z

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