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

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