On Wed, Apr 26, 2023 at 7:53 PM Drouvot, Bertrand <bertranddrouvot...@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.