From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Beena Emerson <memissemerson(at)gmail(dot)com> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Support for N synchronous standby servers - take 2 |
Date: | 2015-08-05 02:18:26 |
Message-ID: | CAB7nPqSj-KDYhd7m8JhP1XNmJ7HN96ebsB2eapY=EmV0CVyBag@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 4, 2015 at 8:37 PM, Beena Emerson <memissemerson(at)gmail(dot)com> wrote:
> Robert Haas wrote:
>>Maybe shoehorning this into the GUC mechanism is the wrong thing, and
>>what we really need is a new config file for this. The information
>>we're proposing to store seems complex enough to justify that.
>>
>
> I think the consensus is that JSON is better.
I guess so as well. Thanks for brainstorming the whole thread in a single post.
> And using a new file with multi line support would be good.
This file just contains a JSON blob, hence we just need to fetch its
content entirely and then let the server parse it using the existing
facilities.
> Name of the file: how about pg_syncinfo.conf?
> Backward compatibility: synchronous_standby_names will be supported.
> synchronous_standby_names='pg_syncinfo' indicates use of new file.
This strengthens the fact that parsing is done at SIGHUP, so that
sounds fine to me. We may still find out an application_name that uses
pg_syncinfo but well, that's unlikely to happen...
> JSON format:
> It would contain 2 main keys: "sync_info" and "groups"
> The "sync_info" would consist of "quorum"/"priority" with the count and
> "nodes"/"group" with the group name or node list.
> The optional "groups" key would list out all the "group" mentioned within
> "sync_info" along with the node list.
>
> [...]
>
> Thoughts?
Yes, I think that's the idea. I would let a couple of days to let
people time to give their opinion and objections regarding this
approach though.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2015-08-05 02:47:38 | Re: tablecmds.c and lock hierarchy |
Previous Message | Michael Paquier | 2015-08-05 01:22:15 | Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. ); |