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

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?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company