Re: Standalone synchronous master

Поиск
Список
Период
Сортировка
От Mark Kirkwood
Тема Re: Standalone synchronous master
Дата
Msg-id 52D1B79E.8060509@catalyst.net.nz
обсуждение исходный текст
Ответ на Re: Standalone synchronous master  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: Standalone synchronous master  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Adrian Klaver
Дата:
Сообщение: Re: [GENERAL] pg_upgrade & tablespaces
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: nested hstore patch