@@ -567,21 +567,15 @@ HeapTupleSatisfiesUpdate(), HeapTupleSatisfiesSelf(),
567
567
HeapTupleSatisfiesDirty() and HeapTupleSatisfiesVacuum() are only
568
568
ever used during write transactions, which cannot exist on the standby.
569
569
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
+
571
574
HeapTupleSatisfiesToast() doesn't use MVCC semantics, though that's
572
575
because it doesn't need to - if the main heap row is visible then the
573
576
toast rows will also be visible. So as long as we follow a toast
574
577
pointer from a visible (live) tuple the corresponding toast rows
575
578
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.
585
579
586
580
Other Things That Are Handy to Know
587
581
-----------------------------------
0 commit comments