Re: Hash index: stop registering pin-only bucket pages in WAL (remove REGBUF_NO_CHANGE)

Hello,

Thanks Vignesh for catching that, and the 068b test.
Also, thanks Hayato-san for the review and comments.

Agreed, InHotStandby becomes true as soon as the first
XLOG_RUNNING_XACTS is replayed, well before recovery reaches
consistency, so with hot_standby = on redo can still read the torn page
in that window. Thanks for the 068b reproducer.

v7 uses HotStandbyActiveInReplay() instead, as you suggested. That is
true only after recovery has reached consistency and the postmaster has
been told connections can start, so there is no scan to serialize
against before then, and by then any full-page image that repairs the
page has been replayed. I made HotStandbyActiveInReplay() extern for
this. 068b now passes, and so does 068a.

I folded your 068b into 0001 next to 068a, with one change: the primary
bucket page is found from blkref #0 or #1, since after 0002 the page is
registered as block 0 rather than 1 when it is the modified page, and
the test runs against the whole series as well as master.

I've applied both of Hayato-san's comments in 0002:
hash_xlog_lock_bucket() is renamed to hash_xlog_lock_primary_bucket(),
and the "block 0 is absent" comment now reads:

/*
* If the primary bucket page is modified, it is registered as block 0
* and read for redo. Otherwise, acquire its cleanup lock separately.
*/

v7:
0001 Fix hash index redo reading a torn primary bucket page
(now with 068a and 068b, and HotStandbyActiveInReplay)
0002 Don't register pin-only primary bucket pages in hash WAL records
(hash_xlog_lock_primary_bucket, carries the same guard)
0003 Add a recovery test for the hash WAL pin-only bucket page fix
0004 Remove REGBUF_NO_CHANGE

0001 stands on its own against master; the rest build on it.

best.

-greg