On Sat, Jan 9, 2016 at 5:13 AM, Simon Riggs <si...@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? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
