Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit9067b83

Browse files
Update nbtree README's "Scans during Recovery".
get_actual_variable_range() hasn't used a dirty snapshot since commit3ca930f, which invented a new snapshot type specifically to meetselfuncs.c's requirements (HeapTupleSatisfiesNonVacuumable() typesnapshots were added).Discussion:https://postgr.es/m/CAH2-Wzn2pSqEOcBDAA40CnO82oEy-EOpE2bNh_XL_cfFoA86jw@mail.gmail.com
1 parent6d7547c commit9067b83

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

Lines changed: 4 additions & 10 deletions
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)
[8]ページ先頭
©2009-2025 Movatter.jp