On 25/09/2026 4:21 AM, Jeff Davis wrote:
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
Paul has found and fixed original problem at primary side:
https://www.postgresql.org/message-id/178956158235.97809.18200289969141907831%40mail.gmail.com
But the proposed patch is still worth keeping as a standby self-heal for
any other invalid bytes under a high |flushedUpto| (other producer bugs,
CF 5199-style missing file, on-disk junk) still hang without it. The
included test demonstrates it.
