Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 9067b83

Browse files
Update nbtree README's "Scans during Recovery".
get_actual_variable_range() hasn't used a dirty snapshot since commit 3ca930f, 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
1 parent 6d7547c commit 9067b83

File tree

1 file changed

+4
-10
lines changed
  • src/backend/access/nbtree

1 file changed

+4
-10
lines changed

src/backend/access/nbtree/README

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

586580
Other Things That Are Handy to Know
587581
-----------------------------------

0 commit comments

Comments
 (0)