Re: How can end users know the cause of LR slot sync delays?

On Tue, Nov 25, 2025 at 5:18 PM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.com> wrote:
>
> Here is the patch to modify the test.
>

+##################################################
+# Verify that slotsync skip statistics are correctly updated when the
+# slotsync operation is skipped.
+##################################################
....
+$standby2->reload;
+
+# Commit the pending prepared transaction
+$primary->safe_psql('postgres', "COMMIT PREPARED 'test_twophase_slotsync';");
+$primary->wait_for_replay_catchup($standby2);
+
+# Remove all logical replication slots on the primary server to ensure the
+# corresponding synced slots are also removed. This guarantees that the safest
+# catalog_xmin on the standby is not preserved by existing slots,
allowing newly
+# created slots to have a fresher initial catalog_xmin.
+$primary->psql('postgres', qq(
+ SELECT pg_drop_replication_slot('lsub1_slot');
+ SELECT pg_drop_replication_slot('snap_test_slot');
+));
+
+$subscriber2->safe_psql(
+ 'postgres', 'DROP SUBSCRIPTION regress_mysub2;');
+
+$standby2->safe_psql('postgres', "SELECT pg_sync_replication_slots();");
+
+is( $standby2->safe_psql(
+ 'postgres',
+ q{SELECT count(*) = 0 FROM pg_replication_slots WHERE slot_name IN
('lsub1_slot', 'lsub2_slot', 'snap_test_slot');}
+ ),
+ "t",
+ 'synchronized slot has been dropped');

This is too much dependency of previous tests on the new one. We
should do cleanup of previous tests separately, if we want to use some
existing set up. Also, do we need to ensure that standby2's slots are
dropped? Did we ever sync slots on standby2? If so, cleaning up here
looks odd. This is to make new tests rely less on the outcome of
previous tests.

-- 
With Regards,
Amit Kapila.