postgresql.git/doc, 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

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

pg_plan_advice: Disallow partition name without partition schema.

2026-09-17T01:09:39Z

Up until now, pg_plan_advice has had a feature that allows an advice target to mention a partition name but omit the partition schema; that is, something like SEQ_SCAN(foo/bar) forces a sequential scan on every child of table foo whose partition name is bar, regardless of the schema in which bar appears. However, that feature turns out to have a nasty design flaw: while advice enforcement handles this case just fine, the advice feedback code doesn't know about it and will mark such advice as "matched, failed" even when everything worked perfectly. Unfortunately, there seems to be no simple code fix for this problem. Since the release of PostgreSQL 19 is imminent, take the conservative course and revert this feature of pg_plan_advice. In other words, require the partition schema whenever the partition name is present. You must now write e.g. SEQ_SCAN(foo/public.bar) rather than just SEQ_SCAN(foo/bar). This doesn't affect any cases where automatically generated advice is supplied, since generated advice has always included the partition schema anyway. Manually written advice will have to conform to the new, stricter rule. For a later release, we can consider whether to again relax this restriction in some way, but now is not the time to design new things. Reported-by: Noah Misch Backpatch-through: 19 Discussion: https://postgr.es/m/CA+TgmoYmXy-jiP5qDhqNEiYFEBzQsArO6O2d9E8szNZqi1bePQ@mail.gmail.com

Revert online data checksum transitions

2026-09-16T09:01:27Z

The feature to enable, or disable, data checksums in an online cluster saw a number of postcommit fixes during the beta period. Suspicions were raised about the risk of more issues surfacing after GA. To avoid shipping code which may have bugs, this reverts in full, or in part, the following commits: aaf8b9989f7, cd857dec0e0, 5fee7cab1b8, 25b922ec582, 8fb8ded8895, b3a37ffbc5b, abac86c7a27, 3a18526e8d6, 01805b7d16b, 343d98c3601, e469e4784ea, 8d22f523245, e5e1f6dc795, 5ab239c9a90, 0ca1b301059, 9a39056c418, 2018bd61679, 1df361e3d82, bf25e5571b3, 381d19da153, b120358c612, 07009121c23, d771b0a907e, f19c0eccae9, 0907112d388, 397f0fd06ed, 602f19c84ca, e3a27cad462, 4ae3e98c02c, b364828f825 A few bits remain as they have merit on their own: * The fix for offline checksums not preserving initial state in pg_control_init. The test case for this fix has been moved to src/bin/pg_checksums/t/002_actions.pl to survive the revert which removed the previous location. * When a page verification is logged, the additional note which informs if the buffer will be zeroed out was kept to aid any debugging around checksum failures. * The Data Checksum section in the docs was kept, but rewritten to reflect the current state. * The enum containing checksum states is kept and some hardcoded references to the off state (0) are replaced with the label PG_DATA_CHECKSUM_OFF instead. Discussion: https://postgr.es/m/E15AC050-C4B5-488D-BB2D-3C7AC9F89EA8@yesql.se Discussion: https://postgr.es/m/anwm6UPxoVS41QA2@bdtpg Discussion: https://postgr.es/m/CA+Tgmob9NY6m0YNFTQ4nFH2d0iC9SQRruDYxfndGKKzh8OC80w@mail.gmail.com Discussion: https://postgr.es/m/E07A611B-9CF3-4FDB-8CE8-A221E39040EC%40yesql.se

doc: Fix primary status update WAL position description

2026-09-16T07:55:35Z

Commit 5f3a49abf7f changed the primary status update message to report the end of the last inserted WAL record instead of the WAL write position. However, the protocol documentation still described the WAL position field as the latest WAL write position, which no longer matches the message sent by walsender. Update the description of the WAL position field to indicate the end of the last inserted WAL record, matching the implementation. Author: Fujii Masao Reviewed-by: Ayush Tiwari Discussion: https://postgr.es/m/CAHGQGwFn2QfpHDR6cWxd98tqNb5vyguEis8rtqnqidFR36p4QQ@mail.gmail.com Backpatch-through: 19

Fail REPACK in presence of invalid indexes, take 2

2026-09-15T13:40:59Z

Commit 0c5d6269614e was confused about which indexes are potentially problematic to rebuild: we thought only !indisready indexes could fail to rebuild, and thus would attempt to rebuild !indisvalid ones that are "ready" (that is, being maintained by DML but not yet completed). However, that's wrong, because it could be that the validation phase of such an index failed or was interrupted partway through. So, have REPACK throw an error with all !indisvalid indexes, not just those !indisready. (!indisready implies !indisvalid, so this is an expansion of what happened with the previous commit.) Reported-by: shihao zhong Backpatch-through: 19 Discussion: https://postgr.es/m/CAGRkXqRA4YetT8Nu3+1-45+ffTwi2bd1d1eDFME39Y9OPRMytQ@mail.gmail.com

doc: Database and tablespace size functions throws error

2026-09-15T11:46:52Z

Commit b6463ea6ef3e46 added an explicit ereport on missing object to pg_database_size and pg_tablespace_size, but the documentation wasn't updated to match. Author: Zhong ShiHao Reviewed-by: Chao Li Reviewed-by: solai v Discussion: https://postgr.es/m/CAGRkXqQSegqDnkRf344G=80mJMn78o9u=auHnx=u1jf=XpuE0A@mail.gmail.com Backpatch-through: 18

Revert UPDATE/DELETE FOR PORTION OF

2026-09-15T10:16:42Z

List of commits reverted: 8e72d914c52 Add UPDATE/DELETE FOR PORTION OF b6ccd30d8ff Add isolation tests for UPDATE/DELETE FOR PORTION OF 33db6c4baf1 Fix DELETE/UPDATE FOR PORTION OF with rules 7b22f15a015 Add psql tab completion for FOR PORTION OF clause 7ca8c942967 Fix FOR PORTION OF with non-updatable view columns 993a7aa0e4a Fix cross-leftover pollution in FOR PORTION OF insert triggers 7ac030d5b15 Require UPDATE permission on FOR PORTION OF column f0aedc7cb0e Small terminology fixes in comments 7d13b03a2e6 Fix FOR PORTION OF for inheritance children a272a58b942 Move FOR PORTION OF volatile check into planner a40fdf65886 Reject child partition FDWs in FOR PORTION OF bc3ae886a75 Forbid FOR PORTION OF with WHERE CURRENT OF c8d49ffb007 Forbid generated columns in FOR PORTION OF 5b5e99047ab Forbid FOR PORTION OF on views with INSTEAD OF triggers c58c83ce50c Fix RLS checks for FOR PORTION OF leftover rows 5454fe4a6e7 Test what BEFORE UPDATE triggers do to FOR PORTION OF 2a9541ddfd3 Deparse FOR PORTION OF using the range column's current name. fd92f74b91d Avoid RETURNING side effects for FOR PORTION OF leftovers. f3a116a26ff Enforce WITH CHECK OPTION on DELETE FOR PORTION OF leftovers c7e34c31e84 Fix error code for null FOR PORTION OF target 938f4f8f343 Fix assertion failures in DELETE FOR PORTION OF tuple routing f1940321687 Resolve untyped parameters in FOR PORTION OF FROM/TO bounds 98f6984e5c0 Don't evaluate the FOR PORTION OF target under EXPLAIN plus release notes entries. Discussion: https://www.postgresql.org/message-id/62bf70cc-dc33-4188-8070-a8c177bb61de%40eisentraut.org

doc: Synopsis placeholder consistency

2026-09-15T08:33:50Z

Make the placeholder for SUPPORT for CREATE AGGREGATE match the previously existing use for CREATE FUNCTION (psfunc -> support_function).