]> granicus.if.org Git - postgresql/commit
Avoid pin scan for replay of XLOG_BTREE_VACUUM in all cases
authorAlvaro Herrera <alvherre@alvh.no-ip.org>
Thu, 17 Nov 2016 16:31:30 +0000 (13:31 -0300)
committerAlvaro Herrera <alvherre@alvh.no-ip.org>
Thu, 17 Nov 2016 16:31:30 +0000 (13:31 -0300)
commitf5d89443203480e39a6a15e64f1950c3b4d3c9a2
tree63b27aedeb6b7e277a1fa9e704ba445f628244d6
parenta69e6d9a6cd9fef893f4cf5b29a9ccf1b015c317
Avoid pin scan for replay of XLOG_BTREE_VACUUM in all cases

Replay of XLOG_BTREE_VACUUM during Hot Standby was previously thought to
require complex interlocking that matched the requirements on the
master. This required an O(N) operation that became a significant
problem with large indexes, causing replication delays of seconds or in
some cases minutes while the XLOG_BTREE_VACUUM was replayed.

This commit skips the “pin scan” that was previously required, by
observing in detail when and how it is safe to do so, with full
documentation. The pin scan is skipped only in replay; the VACUUM code
path on master is not touched here.

No tests included. Manual tests using an additional patch to view WAL records
and their timing have shown the change in WAL records and their handling has
successfully reduced replication delay.

This is a back-patch of commits 687f2cd7a0153e4b7d87988fb60284261375
by Simon Riggs, to branches 9.4 and 9.5.  No further backpatch is
possible because this depends on catalog scans being MVCC.  I (Álvaro)
additionally updated a slight problem in the README, which explains why
this touches the 9.6 and master branches.
src/backend/access/nbtree/README