Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication

Hi,

On Mon, Apr 13, 2026 at 1:40 PM Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> wrote:
>
> Hi,
>
> On Sat, Apr 11, 2026 at 10:04 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Fri, Mar 20, 2026 at 2:08 PM Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> wrote:
> > >
> > > On Fri, Mar 20, 2026 at 1:21 PM Hou, Zhijie/侯 志杰 <houzj(dot)fnst(at)fujitsu(dot)com> wrote:
> > > >
> > > > Since we're reusing the same parser for two GUCs that have different
> > > > interpretations of one syntax variant (the plain slot list), making the parser
> > > > more general is a natural approach, especially given that the patch is adding
> > > > new functionality here.
> > > >
> > > > My main concern is the IsPrioritySyncStandbySlotsSyntax() function. It
> > > > introduces additional hard-coded parsing logic that duplicates what's already
> > > > implemented in syncrep_gram.y. I'm also concerned about maintainability,
> > > > particularly since we already discovered a bug in the hard-coded parser code [1]
> > > > and the patch even added a tap-test (part E) to cover that path. All of this
> > > > effort could be avoided by removing this function and leveraging functionality
> > > > provided by the shared parser.
> > > >
> > >
> > > The issue that you are referring to here was without this function.
> > >
> > > The idea here is to reuse the existing synchronous_standby_names
> > > parser as-is, without changing its grammar or parse behavior.
> > > synchronized_standby_slots differs only in post-parse interpretation
> > > of simple-list syntax, so we add a local helper to disambiguate
> > > explicit priority mode from plain lists before applying
> > > synchronized_standby_slots semantics.
> > >
> >
> > How about splitting the patch to separate out the ANY configuration as
> > the first patch? Then we can focus on the FIRST configuration
> > separately and it would be easier to evaluate whether changing the
> > parser for it is worth the additional complexity.
> >
>
> That sounds like a good approach. I’ll split the current patch into
> two parts, with support for the ANY-based syntax being the first
> patch, and share it.
>

I've incorporated Ajin's incremental patch - [1] which includes the
test case for logical walsender waiting on an active but lagging
standby slot into the last main patch "v20260408-0001*.patch" - [2],
and split it into two parts as suggested: the first one adds
quorum-based syntax support for synchronized_standby_slots, and the
second adds priority-based support (FIRST N). The two patches are
attached below.

Please take a look and share your thoughts.

Hou-san's suggestion to update the common syncrep parser logic for the
second patch is not included for now. I'll wait to hear from Amit and
others before deciding whether to incorporate it.

[1] - https://www.postgresql.org/message-id/CAFPTHDZFtHyJ3bijxcsTqgF%2BN3XseLGrWseiXDTGPJ%2BNM0AhdA%40mail.gmail.com
[2] - https://www.postgresql.org/message-id/CAE9k0P%3DJF_SRrYHb2t7CW-_We-vt1bsJForByf4cwYkgeQAJtg%40mail.gmail.com

--
With Regards,
Ashutosh Sharma.