Race condition between hot standby and restoring a FPW

There's a race condition between a backend running queries in hot
standby mode, and restoring a full-page image from a WAL record. It's
present in all supported versions.

RestoreBackupBlockContents does this:

> buffer = XLogReadBufferExtended(bkpb.node, bkpb.fork, bkpb.block,
> RBM_ZERO);
> Assert(BufferIsValid(buffer));
> if (get_cleanup_lock)
> LockBufferForCleanup(buffer);
> else
> LockBuffer(buffer, BUFFER_LOCK_EXCLUSIVE);

If the page is not in buffer cache yet, and a backend reads and locks
the buffer after the above XLogReadBufferExtended call has zeroed it,
but before it has locked it, the backend sees an empty page.

The principle of fixing that is straightforward: the zeroed page should
not be visible to others, even momentarily. Unfortunately, I think
that's going to require an API change to ReadBufferExtended(RBM_ZERO) :-(.

I can think of two ways to fix this:

1. Have ReadBufferExtended lock the page in RBM_ZERO mode, before
returning it. That makes the API inconsistent, as the function would
sometimes lock the page, and sometimes not.

2. When ReadBufferExtended doesn't find the page in cache, it returns
the buffer in !BM_VALID state (i.e. still in I/O in-progress state).
Require the caller to call a second function, after locking the page, to
finish the I/O.

Anyone have a better idea?

- Heikki