Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication

On Tue, Apr 14, 2026 at 6:01 PM Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> wrote:
>
>
> Sure. Attached is the 0003 patch, based on Hou-San's suggestion, which
> refactors the syncrep parser to explicitly represent bare standby
> lists (i.e. those without the ANY or FIRST keyword). I've also
> attached the two preceding patches for completeness.
>
> --

Thanks Ashutosh. I was testing 001 alone (assuming we would like to
commit it standalone).

This part seems problematic in standlaone 001 patch:

+ /*
+ * For synchronized_standby_slots, a comma-separated list means all
+ * listed slots are required. The parser returns num_sync=1 in this
+ * shape, so map it to nmembers to enforce all-mode semantics.
+ */
+ if (syncrep_parse_result->num_sync == 1 &&
+ syncrep_parse_result->syncrep_method == SYNC_REP_PRIORITY &&
+ syncrep_parse_result->nmembers > 1)
+ syncrep_parse_result->num_sync = syncrep_parse_result->nmembers;

With this, 'FIRST 1(standby_1, standby_2)' is convered to wait_for_all
mode, which is not correct and it keeps wiating for standby_2 when
standby_1 has already taken changes. I am not sure what is correct way
to deal with it when it comes to first patch alone. My expectation was
that FIRST-syntax is blocked i.e. it errors out instead of partially
implemented and misbehaving. But if we plan to do so, the challenge
will be how to distinguish actual FIRST and comma separated list
implicitly converted to 'FIRST 1' by syncrep parser. For that we will
need either 003 or IsPrioritySyncStandbySlotsSyntax', thus defeating
the whole purpose of separating the patches. What do you think on
this? 001 is okay as is or we shall block FIRST?

thanks
Shveta