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
