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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers