From: Peter Geoghegan Date: Tue, 17 Dec 2019 01:11:35 +0000 (-0800) Subject: Update nbtree README's "Scans during Recovery". X-Git-Tag: REL_13_BETA1~1023 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=9067b83955da5fde49a2605510900e6d9fa273af;p=thirdparty%2Fpostgresql.git Update nbtree README's "Scans during Recovery". 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 --- diff --git a/src/backend/access/nbtree/README b/src/backend/access/nbtree/README index 6db203e75cf..246e7a9f027 100644 --- a/src/backend/access/nbtree/README +++ b/src/backend/access/nbtree/README @@ -567,21 +567,15 @@ HeapTupleSatisfiesUpdate(), HeapTupleSatisfiesSelf(), HeapTupleSatisfiesDirty() and HeapTupleSatisfiesVacuum() are only ever used during write transactions, which cannot exist on the standby. 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 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 pointer from a visible (live) tuple the corresponding toast rows 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 -----------------------------------