From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Beena Emerson <memissemerson(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Support for N synchronous standby servers - take 2 |
Date: | 2015-07-14 01:45:53 |
Message-ID: | CAHGQGwHni4KSgiGchhMY1mrTCM_Ez9x2LJQ-hE7vZZ3EvVPypw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jul 14, 2015 at 9:00 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Mon, Jul 13, 2015 at 10:34 PM, Fujii Masao wrote:
>> On Fri, Jul 10, 2015 at 10:06 PM, Beena Emerson wrote:
>>> On Tue, Jul 7, 2015 at 2:19 PM, Michael Paquier wrote:
>>>
>>>> Something like pg_syncinfo/ coupled with a LW lock, we already do
>>>> something similar for replication slots with pg_replslot/.
>>>
>>> I was trying to figure out how the JSON metadata can be used.
>>> It would have to be set using a given set of functions.
>>
>> So we can use only such a set of functions to configure synch rep?
>> I don't like that idea. Because it prevents us from configuring that
>> while the server is not running.
>
> If you store a json blob in a set of files of PGDATA you could update
> them manually there as well. That's perhaps re-inventing the wheel
> with what is available with GUCs though.
Why don't we just use GUC? If the quorum setting is not so complicated
in real scenario, GUC seems enough for that.
Regards,
--
Fujii Masao
From | Date | Subject | |
---|---|---|---|
Next Message | David Guimaraes | 2015-07-14 01:58:52 | Re: Forensic recovery deleted pgdump custom format file |
Previous Message | Andrew Dunstan | 2015-07-14 01:28:44 | Re: PostgreSQL 9.5 Alpha 1 build fail with perl 5.22 |