@@ -567,21 +567,15 @@ HeapTupleSatisfiesUpdate(), HeapTupleSatisfiesSelf(),
567567HeapTupleSatisfiesDirty() and HeapTupleSatisfiesVacuum() are only
568568ever used during write transactions, which cannot exist on the standby.
569569MVCC 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+
571574HeapTupleSatisfiesToast() doesn't use MVCC semantics, though that's
572575because it doesn't need to - if the main heap row is visible then the
573576toast rows will also be visible. So as long as we follow a toast
574577pointer from a visible (live) tuple the corresponding toast rows
575578will 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
586580Other Things That Are Handy to Know
587581-----------------------------------