Thread: multiple entries for synchronous_standby_names

multiple entries for synchronous_standby_names

From
Nitesh Nathani
Date:

Trying to achieve sync streaming to barman server and i need to add an entry to postgresql.conf for this parameter, which already has an entry and tried a few variations but does not work. Any ideas? Also tried '&&' but in vain

synchronous_standby_names='ANY 1 (*)',barman-wal-archive

log excerpt:

2022-06-10 16:50:54.272 BST [11241-43] @ app= LOG: syntax error in file "/var/lib/pgsql/13/data/postgresql.conf" line 22, near token "," 2022-06-10 16:50:54.272 BST [11241-44] @ app= LOG: configuration file "/var/lib/pgsql/13/data/postgresql.conf" contains errors; no changes were applied

Re: multiple entries for synchronous_standby_names

From
Michael Paquier
Date:
On Fri, Jun 10, 2022 at 05:04:30PM +0100, Nitesh Nathani wrote:
> Trying to achieve sync streaming to barman server and i need to add an
> entry to postgresql.conf for this parameter, which already has an entry and
> tried a few variations but does not work. Any ideas? Also tried '&&' but in
> vain
>
> synchronous_standby_names='ANY 1 (*)',barman-wal-archive

This grammar flavor is not supported (see also syncrep_gram.y for the
code):
https://www.postgresql.org/docs/devel/runtime-config-replication.html

And here is the actual list of grammars supported:
[FIRST] num_sync ( standby_name [, ...] )
ANY num_sync ( standby_name [, ...] )
standby_name [, ...]

In short, you can specify a list of node names within one ANY or FIRST
clause, but you cannot specify a list made of ANY/FIRST items.
Without knowing what kind of priority policy you are trying to
achieve, it is hard to recommend one method over the others.  What we
support now has proven to be hard enough to implement and to make
robust, and supporting sub-groups of nodes was also on the table back
in the day, but the lack of cases did not justify the extra
implementation complexity, as far as I recall this matter.
--
Michael

Attachment