On Sat, Jan 9, 2016 at 5:13 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > Avoid pin scan for replay of XLOG_BTREE_VACUUM > 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. > > The current commit still performs the pin scan for toast indexes, though this > can also be avoided if we recheck scans on toast indexes. Later patch will > address this. > > 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.
I suspect I might be missing something here, but I don't see how a test against rel->rd_rel->relnamespace can work during recovery. Won't the relcache entry we're looking at here be one created by CreateFakeRelcacheEntry(), and thus that field won't be valid?
The test isn't made during recovery, its made on the master.
--
Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
