On Wed, Apr 26, 2023 at 7:53 PM Drouvot, Bertrand
<bertranddrouvot.pg@gmail.com> wrote:
>
> > Besides, would it be better to wait for the cascading standby? If the wal log
> > file needed for cascading standby is removed on the standby, the subsequent test
> > will fail.
>
> Good catch! I agree that we have to wait on the cascading standby before removing
> the WAL files. It's done in V6 (and the test is not failing anymore if we set a
> recovery_min_apply_delay to 5s on the cascading standby).
>
+# Get the restart_lsn from an invalidated slot
+my $restart_lsn = $node_standby->safe_psql('postgres',
+ "SELECT restart_lsn from pg_replication_slots WHERE slot_name =
'vacuum_full_activeslot' and conflicting is true;"
+);
+
+chomp($restart_lsn);
+
+# Get the WAL file name associated to this lsn on the primary
+my $walfile_name = $node_primary->safe_psql('postgres',
+ "SELECT pg_walfile_name('$restart_lsn')");
+
+chomp($walfile_name);
+
+# Check the WAL file is still on the primary
+ok(-f $node_primary->data_dir . '/pg_wal/' . $walfile_name,
+ "WAL file still on the primary");
How is it guaranteed that the WAL file corresponding to the
invalidated slot on standby will still be present on primary? Can you
please explain the logic behind this test a bit more like how the WAL
file switch helps you to achieve the purpose?
--
With Regards,
Amit Kapila.
