Re: [PATCH] Harden recovery/t/051_effective_wal_level against WAL recycling

On 8/8/26 22:44, Bryan Green wrote:
> Greetings,
>
> In recovery/t/051_effective_wal_level.pl, standby3, standby4, and standby5
> are all init_from_backup()'d from 'my_backup', taken near the top of the
> test, and started much later, after the primary has produced and recycled a
> lot of WAL.  Nothing keeps the WAL they need to reach consistency: no slot
> covering it, no wal_keep_size, no archive.  (standby5 has phys_slot, but a
> physical slot only pins WAL from its own creation, not the older WAL needed
> to replay from 'my_backup'.)  So each one starts only because the primary
> happens not to have recycled that WAL yet.
>
> That holds with the default WAL page layout but is fragile: anything that
> consumes WAL address space a bit faster can push the needed segment out of
> the retention window, and the standby then fails to start with "requested
> WAL segment ... has already been removed".  These standbys are scaffolding
> for the promotion, logical-decoding, and slot-synchronization tests, not a
> test of WAL recycling.
>
> The fix takes a fresh backup immediately before each of them, so the start
> point is recent and within retained WAL regardless of what the earlier part
> of the test produced.
>
> It depends on retention timing, so there's no on-demand reproduction; the
> change is justified by the structure (late standbys restoring from an early,
> unpinned backup).  051 passes with injection points enabled, so all three
> standby blocks run.
>
> --
> Bryan Green
> EDB: https://www.enterprisedb.com
I have a use case that is not stock PG that this is related to. I'm
withdrawing this.

--
Bryan Green
EDB: https://www.enterprisedb.com