Re: Support for N synchronous standby servers

On Fri, Sep 19, 2014 at 12:18 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Sep 16, 2014 at 2:19 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> On Tue, Sep 16, 2014 at 5:25 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> On Mon, Sep 15, 2014 at 3:00 PM, Michael Paquier
>>> <michael.paquier@gmail.com> wrote:
>>>> At least a set of hooks has the merit to say: do what you like with
>>>> your synchronous node policy.
>>>
>>> Sure.  I dunno if people will find that terribly user-friendly, so we
>>> might not want that to be the ONLY thing we offer.
>> Well, user-friendly interface is actually the reason why a simple GUC
>> integer was used in the first series of patches present on this thread
>> to set as sync the N-nodes with the lowest priority. I could not come
>> up with something more simple. Hence what about doing the following:
>> - A patch refactoring code for pg_stat_get_wal_senders and
>> SyncRepReleaseWaiters as there is in either case duplicated code in
>> this area to select the synchronous node as the one connected with
>> lowest priority
>
> A strong +1 for this idea.  I have never liked that, and cleaning it
> up seems eminently sensible.

Interestingly, the syncrep code has in some of its code paths the idea
that a synchronous node is unique, while other code paths assume that
there can be multiple synchronous nodes. If that's fine I think that
it would be better to just make the code multiple-sync node aware, by
having a single function call in walsender.c and syncrep.c that
returns an integer array of WAL sender positions (WalSndCtl). as that
seems more extensible long-term. Well for now the array would have a
single element, being the WAL sender with lowest priority > 0. Feel
free to protest about that approach though :)

>> - A patch defining the hooks necessary, I suspect that two of them are
>> necessary as mentioned upthread.
>> - A patch for a contrib module implementing an example of simple
>> policy. It can be a fancy thing with a custom language or even a more
>> simple thing.
>
> I'm less convinced about this part.  There's a big usability gap
> between a GUC and a hook, and I think Heikki's comments upthread were
> meant to suggest that even in GUC-land we can probably satisfy more
> use cases that what this patch does now.  I think that's right.
Hehe. OK then let's see how something with a GUC would go then. There
is no parameter now using a custom language as format base, but I
guess that it is fine to have a text parameter with a validation
callback within. No?
-- 
Michael