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. -- Simon Riggs http://www.2ndQuadrant.com/ <http://www.2ndquadrant.com/> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
