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

Commitf65b94f

Browse files
committed
Avoid pin scan for replay of XLOG_BTREE_VACUUM in all cases
Replay of XLOG_BTREE_VACUUM during Hot Standby was previously thought torequire complex interlocking that matched the requirements on themaster. This required an O(N) operation that became a significantproblem with large indexes, causing replication delays of seconds or insome cases minutes while the XLOG_BTREE_VACUUM was replayed.This commit skips the “pin scan” that was previously required, byobserving in detail when and how it is safe to do so, with fulldocumentation. The pin scan is skipped only in replay; the VACUUM codepath on master is not touched here.No tests included. Manual tests using an additional patch to view WAL recordsand their timing have shown the change in WAL records and their handling hassuccessfully reduced replication delay.This is a back-patch of commits687f2cd,3e4b7d8,b602842by Simon Riggs, to branches 9.4 and 9.5. No further backpatch ispossible because this depends on catalog scans being MVCC. I (Álvaro)additionally updated a slight problem in the README, which explains whythis touches the 9.6 and master branches.
1 parent380895f commitf65b94f

File tree

1 file changed

+3
-2
lines changed
  • src/backend/access/nbtree

1 file changed

+3
-2
lines changed

‎src/backend/access/nbtree/README

Lines changed: 3 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -521,11 +521,12 @@ because it allows running applications to continue while the standby
521521
changes state into a normally running server.
522522

523523
The interlocking required to avoid returning incorrect results from
524-
MVCC scans is not required on standby nodes. That is because
524+
non-MVCC scans is not required on standby nodes. That is because
525525
HeapTupleSatisfiesUpdate(), HeapTupleSatisfiesSelf(),
526526
HeapTupleSatisfiesDirty() and HeapTupleSatisfiesVacuum() are only
527527
ever used during write transactions, which cannot exist on the standby.
528-
This leaves HeapTupleSatisfiesMVCC() and HeapTupleSatisfiesToast().
528+
MVCC scans are already protected by definition, so HeapTupleSatisfiesMVCC()
529+
is not a problem. That leaves concern only for HeapTupleSatisfiesToast().
529530
HeapTupleSatisfiesToast() doesn't use MVCC semantics, though that's
530531
because it doesn't need to - if the main heap row is visible then the
531532
toast rows will also be visible. So as long as we follow a toast

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp