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