Re: Support for N synchronous standby servers

On Tue, Sep 16, 2014 at 2:19 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Tue, Sep 16, 2014 at 5:25 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Mon, Sep 15, 2014 at 3:00 PM, Michael Paquier
>> <michael(dot)paquier(at)gmail(dot)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.

> - 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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company