database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-08-05 07:41:25 +03:00
Code Activity

Update nbtree README's "Scans during Recovery".

Browse Source 
get_actual_variable_range() hasn't used a dirty snapshot since commit
3ca930fc3, which invented a new snapshot type specifically to meet
selfuncs.c's requirements (HeapTupleSatisfiesNonVacuumable() type
snapshots were added).

Discussion: https://postgr.es/m/CAH2-Wzn2pSqEOcBDAA40CnO82oEy-EOpE2bNh_XL_cfFoA86jw@mail.gmail.com
This commit is contained in:
Peter Geoghegan
2019-12-16 17:11:35 -08:00
parent 6d7547c219
commit 9067b83955
1 changed files with 4 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -567,21 +567,15 @@ HeapTupleSatisfiesUpdate(), HeapTupleSatisfiesSelf(),
HeapTupleSatisfiesDirty() and HeapTupleSatisfiesVacuum() are only HeapTupleSatisfiesDirty() and HeapTupleSatisfiesVacuum() are only
ever used during write transactions, which cannot exist on the standby. ever used during write transactions, which cannot exist on the standby.
MVCC scans are already protected by definition, so HeapTupleSatisfiesMVCC() MVCC scans are already protected by definition, so HeapTupleSatisfiesMVCC()
is not a problem. That leaves concern only for HeapTupleSatisfiesToast(). is not a problem. The optimizer looks at the boundaries of value ranges
using HeapTupleSatisfiesNonVacuumable() with an index-only scan, which is
also safe. That leaves concern only for HeapTupleSatisfiesToast().
HeapTupleSatisfiesToast() doesn't use MVCC semantics, though that's HeapTupleSatisfiesToast() doesn't use MVCC semantics, though that's
because it doesn't need to - if the main heap row is visible then the because it doesn't need to - if the main heap row is visible then the
toast rows will also be visible. So as long as we follow a toast toast rows will also be visible. So as long as we follow a toast
pointer from a visible (live) tuple the corresponding toast rows pointer from a visible (live) tuple the corresponding toast rows
will also be visible, so we do not need to recheck MVCC on them. will also be visible, so we do not need to recheck MVCC on them.
There is one minor exception, which is that the optimizer sometimes
looks at the boundaries of value ranges using SnapshotDirty, which
could result in returning a newer value for query statistics; this
would affect the query plan in rare cases, but not the correctness.
The risk window is small since the stats look at the min and max values
in the index, so the scan retrieves a tid then immediately uses it
to look in the heap. It is unlikely that the tid could have been
deleted, vacuumed and re-inserted in the time taken to look in the heap
via direct tid access. So we ignore that scan type as a problem.
Other Things That Are Handy to Know Other Things That Are Handy to Know
----------------------------------- -----------------------------------