Refactoring code for sync node detection (was: Support for N synchronous standby servers)

On Sat, Sep 20, 2014 at 1:16 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Fri, Sep 19, 2014 at 12:18 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Tue, Sep 16, 2014 at 2:19 PM, Michael Paquier
>> <michael(dot)paquier(at)gmail(dot)com> wrote:
>>> - 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 :)
Please find attached a patch refactoring this code. Looking once again
at that I have taken the approach minimizing the footprint of
refactoring on current code, by simply adding a function called
SyncRepGetSynchronousNode in syncrep.c that returns to the caller a
position in the WAL sender array to define the code considered as
synchronous, and if no synchronous node is found.

I'll add it to the next commit fest.

Regards,
--
Michael