Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication - Mailing list pgsql-hackers

From shveta malik
Subject Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication
Date
Msg-id CAJpy0uAY6oe9Ln7+EgqqpB+F8-2J0G=L9wZDcdFVrVfYJYLAJQ@mail.gmail.com
Whole thread
In response to Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication  (Ashutosh Sharma <ashu.coek88@gmail.com>)
Responses Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication
List pgsql-hackers
On Thu, Apr 2, 2026 at 3:55 PM Ashutosh Sharma <ashu.coek88@gmail.com> wrote:
>
> Hi Shveta,
>
> On Wed, Apr 1, 2026 at 12:06 PM shveta malik <shveta.malik@gmail.com> wrote:
> >
> > On Thu, Mar 26, 2026 at 5:23 PM Ashutosh Sharma <ashu.coek88@gmail.com> wrote:
> > >
> > >
> > > PFA patch addressing all the comments above and let me know for any
> > > further comments.
> > >
> >
> > Thank You Ashutosh. Doc looks good to me. Few comments:
> >
> > 3)
> > What is the execution time for this new test?
> > I ran it on my VM (which is slightly on the slower side), and the
> > runtime varies between ~60 seconds and ~140 seconds. I executed it
> > around 10–15 times. Most runs completed in about 65 seconds (which is
> > still more), but a few were significantly longer (100+ seconds).
> > During the longer runs, I noticed the following entry in pub.log
> > (possibly related to Test Scenario E taking more time?). Could you
> > please try running this on your end as well?
> >
> > 2026-03-31 19:45:45.557 IST client backend[145705]
> > 053_synchronized_standby_slots_quorum.pl LOG:  statement: SELECT
> > active_pid IS NOT NULL
> >   AND restart_lsn IS NOT NULL
> >   AND restart_lsn < '0/03000450'::pg_lsn
> > FROM pg_replication_slots
> > WHERE slot_name = 'sb1_slot';
> >
> > Just for reference, the complete  failover test
> > (t/040_standby_failover_slots_sync.pl) takes somewhere between 7 to
> > 10sec on my VM.
> >
>
> My concern with this new test is that it's both slow to run and prone
> to flakiness, which makes me question whether it's worth keeping.
>

will review and share my thoughts.

thanks
Shveta



pgsql-hackers by date:

Previous
From: Chao Li
Date:
Subject: Re: Small and unlikely overflow hazard in bms_next_member()
Next
From: Haibo Yan
Date:
Subject: Re: Extract numeric filed in JSONB more effectively