Re: Support for N synchronous standby servers - take 2

On Wed, Jul 1, 2015 at 11:58 PM, Sawada Masahiko wrote:
> On Tue, Jun 30, 2015 at 2:40 AM, Josh Berkus wrote:
>>
>> BTW, ALTER SYSTEM is a strong reason to use JSON for the synch rep GUC
>> (assuming it's one parameter) instead of some custom syntax. If it's
>> JSON, we can validate it in psql, whereas if it's some custom syntax we
>> have to wait for the db to reload and fail to figure out that we forgot
>> a comma. Using JSON would also permit us to use jsonb_set and
>> jsonb_delete to incrementally change the configuration.
>
> Sounds convenience and flexibility. I agree with this json format
> parameter only if we don't combine both quorum and prioritization.
> Because of backward compatibility.
> I tend to use json format value and it's new separated GUC parameter.

This is going to make postgresql.conf unreadable. That does not look
very user-friendly, and a JSON object is actually longer in characters
than the formula spec proposed upthread.

> Anyway, if we use json, I'm imaging parameter values like below.
> [JSON]
>> Question: what happens *today* if we have two different synch rep
>> strings in two different *.conf files? I wouldn't assume that anyone
>> has tested this ...
> We use last defied parameter even if sync rep strings in several file, right?

The last one wins, that's the rule in GUCs. Note that
postgresql.auto.conf has the top priority over the rest, and that
files included in postgresql.conf have their value considered when
they are opened by the parser.

Well, the JSON format has merit, if stored as metadata in PGDATA such
as it is independent on WAL, in something like pg_syncdata/ and if it
can be modified with a useful interface, which is where Josh's first
idea could prove to be useful. We just need a clear representation of
the JSON schema we would use and with what kind of functions we could
manipulate it on top of a get/set that can be used to retrieve and
update the metadata as wanted.

In order to preserve backward-compatibility, set s_s_names as
'special_value' and switch to the old interface. We could consider
dropping it after a couple of releases and being sure that the new
system is stable.

Also, I think that we should rely on SIGHUP as a first step of the
implementation to update the status of sync nodes in backend
processes. As a future improvement we could perhaps get rid. Still it
seems safer to me to rely on a signal to update the in-memory status
as a first step as this is what we have now.
--
Michael