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

On Sun, Jan 10, 2016 at 3:50 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> 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.

/me crawls into a hole.

Thanks.

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