Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication

From: Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>
To: shveta malik <shveta(dot)malik(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>
Subject: Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication
Date: 2026-03-26 07:48:43
Message-ID: CAE9k0PkdS92U5qpKMJDb5XKavJL0OxLjohd2b7Km+1sCt6KE6w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 26, 2026 at 12:03 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> On Thu, Mar 26, 2026 at 11:36 AM Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> wrote:
> >
> > Makes sense. The attached patch addresses this too.
> >
> > --
>
> Thanks Ashutosh. I have not yet looked at today's patch, please find a
> few comments from previous one:
>
> 1)
> I noticed a change in behavior compared to the HEAD.
>
> Earlier, inactive slots were considered blocking only if they were
> lagging (restart_lsn < wait_for_lsn). Now, inactive slots are treated
> as blocking regardless of their restart_lsn. I think we should revert
> to the previous behavior. It’s possible for a slot to catch up and
> then become inactive; in such cases, it should still be treated as
> caught up rather than blocking.
>

Oh, absolutely, you're spot on. I will get this (and other things
related to this) fixed in the next patch. Thanks for pointing it out.

--
With Regards,
Ashutosh Sharma.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Lakshmi N 2026-03-26 08:06:37 Re: log XLogPrefetch stats at end of recovery
Previous Message Nikhil Chawla 2026-03-26 07:32:23 Re: [PATCH] Add prepared_orphaned_transaction_timeout GUC