RE: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication

On Saturday, April 11, 2026 12:34 PM 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.

+1

For reference only, I'm attaching a top-up patch (on top of v20260408-0001) that
refactors the parsing logic to distinguish between FIRST and plain lists, as
previously discussed.

Best Regards,
Hou zj