Hello!
Bryan Green <[email protected]> writes: > ... > > 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. I've been in this situation and by experience, reproducing this it's really hard, but it's easier if the test force the situation, so what I've done is add to test, the following lines: $standby2->stop; $cascade->stop; +for (1 .. 10) +{ + $primary->safe_psql('postgres', 'SELECT pg_switch_wal()'); +} +$primary->safe_psql('postgres', 'CHECKPOINT'); + # Initialize standby3 node and start it. Take a fresh backup rather than This was useful to create some WAL files and helped to reproduce the issue, probably is worthy to have this in the test to avoid replicating the same issue in the future? I wonder if there's any other test with a similar issue, but that's not related to this patch at all. Regards, -- Jonathan Gonzalez V. EDB https://www.enterprisedb.com
