On Sun, Jan 10, 2016 at 3:50 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 10 January 2016 at 16:32, Robert Haas <robertmh...@gmail.com> wrote: >> >> 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? > > The test isn't made during recovery, its made on the master.
/me crawls into a hole. Thanks. -- 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
