Re: Standalone synchronous master
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
Cc: Stephen Frost <sfrost@snowman.net>,
Adrian Klaver <adrian.klaver@gmail.com>,
"Joshua D. Drake" <jd@commandprompt.com>, Josh Berkus <josh@agliodbs.com>,
Andres Freund <andres@2ndquadrant.com>, Bruce Momjian <bruce@momjian.us>,
Amit Kapila <amit.kapila16@gmail.com>,
Hannu Krosing <hannu@2ndquadrant.com>, MauMau <maumau307@gmail.com>,
Kevin Grittner <kgrittn@ymail.com>,
Heikki Linnakangas <hlinnakangas@vmware.com>,
Simon Riggs <simon@2ndquadrant.com>,
Rajeev rastogi <rajeev.rastogi@huawei.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2014-01-11T21:59:51Z
Lists: pgsql-hackers
Mark Kirkwood <mark.kirkwood@catalyst.net.nz> writes [slightly rearranged] > My 2c is: > The current behavior in CAP theorem speak is 'Cap' - i.e focused on > consistency at the expense of availability. A reasonable thing to want. > The other behavior being asked for is 'cAp' - i.e focused on > availability. Also a reasonable configuration to want. > I think an option to control whether we operate 'Cap' or 'cAp' > (defaulting to the current 'Cap' I guess) is probably the best solution. The above is all perfectly reasonable. The argument that's not been made to my satisfaction is that the proposed patch is a good implementation of 'cAp'-optimized behavior. In particular, > ... Now the desire to > use sync rather than async is to achieve as much consistency as > possible, which is also reasonable. I don't think that the existing sync mode is designed to do that, and simply lobotomizing it as proposed doesn't get you there. I think we need a replication mode that's been designed *from the ground up* with cAp priorities in mind. There may end up being only a few actual differences in behavior --- but I fear that some of those differences will be crucial. regards, tom lane