Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication

From: shveta malik <shveta(dot)malik(at)gmail(dot)com>
To: Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>
Cc: Japin Li <japinli(at)hotmail(dot)com>, surya poondla <suryapoondla4(at)gmail(dot)com>, SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, shveta malik <shveta(dot)malik(at)gmail(dot)com>
Subject: Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication
Date: 2026-04-01 06:36:32
Message-ID: CAJpy0uBoefn04i6p5WsaUGrXg7O0CvBWqUUARVfPwpSGtvRq=A@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 26, 2026 at 5:23 PM Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)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:

1)
slot_states[num_slot_states].slot_name = name;
slot_states[num_slot_states].state =
inactive ? SS_SLOT_INACTIVE_LAGGING : SS_SLOT_ACTIVE_LAGGING;
if (!inactive)
slot_states[num_slot_states].restart_lsn = restart_lsn;
num_slot_states++;

Just to simplify the above part, I think we can set restart_lsn
irrespective of 'inactive', no harm in that.
Feel free to ignore this comment if you like the current way.

slot_states[num_slot_states].slot_name = name;
slot_states[num_slot_states].restart_lsn = restart_lsn;
slot_states[num_slot_states].state =
inactive ? SS_SLOT_INACTIVE_LAGGING : SS_SLOT_ACTIVE_LAGGING;
num_slot_states++;

2)
Test case mentioned scenarios A,B,C in test header, we can either
mention all there or none.

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.

thanks
Shveta

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2026-04-01 06:43:15 Re: DOCS - DROP SUBSCRIPTION does not document parameter "IF EXISTS"
Previous Message Peter Eisentraut 2026-04-01 06:34:39 Re: Use standard C23 and C++ attributes if available