Re: Standalone synchronous master - Mailing list pgsql-hackers

From Mark Kirkwood
Subject Re: Standalone synchronous master
Date
Msg-id 52D1B79E.8060509@catalyst.net.nz
Whole thread Raw
In response to Re: Standalone synchronous master  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Standalone synchronous master  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 11/01/14 13:25, Stephen Frost wrote:
> Adrian,
>
>
> * Adrian Klaver (adrian.klaver@gmail.com) wrote:
>> A) Change the existing sync mode to allow the master and standby
>> fall out of sync should a standby fall over.
>
> I'm not sure that anyone is argueing for this..
>
>> B) Create a new mode that does this without changing the existing sync mode.
>>
>> My two cents would be to implement B. Sync to me is a contract that
>> master and standby are in sync at any point in time. Anything else
>> should be called something else. Then it is up to the documentation
>> to clearly point out the benefits/pitfalls. If you want to implement
>> something as important as replication without reading the docs then
>> the results are on you.
>
> The issue is that there are folks who are argueing, essentially, that
> "B" is worthless, wrong, and no one should want it and therefore we
> shouldn't have it.
>

We have some people who clearly do want it (and seemed to have provided 
sensible arguments about why it might be worthwhile), and the others who 
say they should not.

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. Now the desire to 
use sync rather than async is to achieve as much consistency as 
possible, which is also reasonable.

I think an option to control whether we operate 'Cap' or 'cAp' 
(defaulting to the current 'Cap' I guess) is probably the best solution.

Regards

Mark




pgsql-hackers by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: [GENERAL] pg_upgrade & tablespaces
Next
From: Andrew Dunstan
Date:
Subject: Re: nested hstore patch