On Fri, May 15, 2015 at 9:18 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Fri, May 15, 2015 at 8:55 PM, Beena Emerson <memissemer...@gmail.com> > wrote: >> There was a discussion on support for N synchronous standby servers started >> by Michael. Refer >> http://archives.postgresql.org/message-id/cab7npqr9c84ig0zuvhmqamq53vqsd4rc82vyci4dr27pvof...@mail.gmail.com >> . The use of hooks and dedicated language was suggested, however, it seemed >> to be an overkill for the scenario and there was no consensus on this. >> Exploring GUC-land was preferred. > > Cool. > >> Please find attached a patch, built on Michael's patch from above mentioned >> thread, which supports choosing different number of nodes from each set i.e. >> k nodes from set 1, l nodes from set 2, so on. >> The format of synchronous_standby_names has been updated to standby name >> followed by the required count separated by hyphen. Ex: 'aa-1, bb-3'. The >> transaction waits for all the specified number of standby in each group. Any >> extra nodes with the same name will be considered potential. The special >> entry * for the standby name is also supported. > > I don't think that this is going in the good direction, what was > suggested mainly by Robert was to use a micro-language that would > allow far more extensibility that what you are proposing. See for > example ca+tgmobpwoenmmepfx0jwrvqufxvbqrv26ezq_xhk21gxrx...@mail.gmail.com > for some ideas. IMO, before writing any patch in this area we should > find a clear consensus on what we want to do. Also, unrelated to this > patch, we should really get first the patch implementing the... Hum... > infrastructure for regression tests regarding replication and > archiving to be able to have actual tests for this feature (working on > it for next CF).
The dedicated language for multiple sync replication would be more extensibility as you said, but I think there are not a lot of user who want to or should use this. IMHO such a dedicated extensible feature could be extension module, i.g. contrib. And we could implement more simpler feature into PostgreSQL core with some restriction. Regards, ------- Sawada Masahiko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
