Re: Recovery at replica stuck because recovery incorrectly trusts an old high-water mark

Hi,

Konstantin Knizhnik <knizhnik(at)garret(dot)ru> wrote:
> I have not re-run the recovery TAP suite against this tree (no local
> install of current master).

I ran it on master 2c10c2ce4d7 with v2 (cassert, injection points):
src/test/recovery passes, 802 tests against 799 on master, the new
ones being 058. Without the C changes, 058 fails as intended, with
startup rereading the corrupt local copy until the timeout.

One ordering issue: the reset of applyFlushedUpto runs after
RequestXLogStreaming(). If the new walreceiver flushes the
replacement bytes before the reset, the pointer goes back below them
and startup waits for the next flush. The window is tiny, but with a
3 s sleep there, replay sat for about 18 s until an unrelated
running-xacts record arrived.

Doing the reset before RequestXLogStreaming() closes it: with the
same sleep there is no stall, and with only that change (attached, on
top of v2) the recovery suite passes and 058 passed 20 of 20 runs.

Logs and the review-only diffs are in the second attachment.

Regards,
Manu