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

On Thu, 2026-09-24 at 21:30 +0300, Konstantin Knizhnik wrote:
> v2 keeps flushedUpto monotonic.  Startup uses a separate
> applyFlushedUpto for "is this streamed WAL readable?"

The reread-from-primary behavior seems to trace to 6da07cd80d, which
looks more like an opportunistic retry than a policy.

We could make it a policy to try to get readable WAL from the primary,
and then keep the extra state you propose. But I think we need more
explanation about why we'd expect this situation (corrupt and flushed
on standby and valid on primary) to occur.

For instance:

/* ...Only after a failed read of
* WAL that flushedUpto still reports as present do we
* rewind the apply pointer, so startup waits for
* replacement bytes.

raises questions for anyone reading that code about why it might be
flushed and unreadable.

Regards,
Jeff Davis