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

Hello!

Bryan Green <dbryan(dot)green(at)gmail(dot)com> 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