Thread

  1. RE: How can end users know the cause of LR slot sync delays?

    Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com> — 2025-11-26T03:24:12Z

    On Wednesday, November 26, 2025 11:00 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
    > 
    > 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.
    
    I think we did not sync slots to standby2, so I removed the checks for that.
    
    I also adjusted the test in a way that it cleans up existing slots before starting
    new tests.
    
    Here is the updated version.
    
    Best Regards,
    Hou zj