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
