Re: [COMMITTERS] pgsql: Avoid pin scan for replay of XLOG_BTREE_VACUUM

On 10 January 2016 at 16:32, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Sat, Jan 9, 2016 at 5:13 AM, Simon Riggs <simon(at)2ndquadrant(dot)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