database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2026-10-23 13:29:09 +03:00
Code Activity

Add nbtree README note on index-only scans in recovery.

Browse Source 
The nbtree README has long claimed that "the interlocking required to
avoid returning incorrect results from non-MVCC scans is not required on
standby nodes".  A recent test case proved that the underlying reasoning
was faulty.

There are significant practical challenges around fixing this bug, and
no user has complained about it so far.  The old "pin scan" mechanism
prevented the problem but performed very poorly.  Since there seems to
be no appetite for resurrecting that mechanism, and since an acceptable
fix hasn't been forthcoming, make a note of the issue for later.

Discussion: https://postgr.es/m/CAH2-Wzkro678xEDOrsxrq-YDVP4w7nXybhVJV2MxrzTj-5OU4w@mail.gmail.com
This commit is contained in:
Peter Geoghegan
2026-10-10 19:38:58 -04:00
parent 173cf85a07
commit 9e7d152488
1 changed files with 3 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
src/backend/access/nbtree/README
View File

@@ -757,8 +757,9 @@ cleanup lock when replaying VACUUM records during recovery, but recovery
does not need to lock every leaf page (only those leaf pages that have
items to delete) -- that's sufficient to avoid breaking index-only scans
during recovery (see section above about making TID recycling safe). That
leaves concern only for plain index scans. (XXX: Not actually clear why
this is totally unnecessary during recovery.)
leaves concern only for plain index scans. (XXX: This reasoning is faulty,
see CAH2-Wzkro678xEDOrsxrq-YDVP4w7nXybhVJV2MxrzTj-5OU4w@mail.gmail.com for
details.)
MVCC snapshot plain index scans are always safe, for the same reasons that
they're safe during original execution. HeapTupleSatisfiesToast() doesn't