Skip site navigation (1) Skip section navigation (2)

Re: Synchronous replication

From: Yeb Havinga <yebhavinga(at)gmail(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Boszormenyi Zoltan <zb(at)cybertec(dot)at>
Subject: Re: Synchronous replication
Date: 2010-07-27 08:42:02
Message-ID: 4C4E9BDA.5070202@gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Fujii Masao wrote:
> On Mon, Jul 26, 2010 at 8:25 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>   
>> On Mon, Jul 26, 2010 at 6:48 AM, Marko Tiikkaja
>> <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi> wrote:
>>     
>>> On 7/26/10 1:44 PM +0300, Fujii Masao wrote:
>>>       
>>>> On Mon, Jul 26, 2010 at 6:36 PM, Yeb Havinga<yebhavinga(at)gmail(dot)com>  wrote:
>>>>         
>>>>> I wasn't entirely clear. My suggestion was to have only
>>>>>
>>>>>   acknowledge_commit = {no|recv|fsync|replay}
>>>>>
>>>>> instead of
>>>>>
>>>>>   replication_mode = {async|recv|fsync|replay}
>>>>>           
>>>> Okay, I'll change the patch accordingly.
>>>>         
>>> For what it's worth, I think replication_mode is a lot clearer.
>>> Acknowledge_commit sounds like it would do something similar to
>>> asynchronous_commit.
>>>       
>> I agree.
>>     
>
> As the result of the vote, I'll leave the parameter "replication_mode"
> as it is.
>   
I'd like to bring forward another suggestion (please tell me when it is 
becoming spam). My feeling about replication_mode as is, is that is says 
in the same parameter something about async or sync, as well as, if 
sync, which method of feedback to the master. OTOH having two parameters 
would need documentation that the feedback method may only be set if the 
replication_mode was sync, as well as checks. So it is actually good to 
have it all in one parameter

But somehow the shoe pinches, because async feels different from the 
other three parameters. There is a way to move async out of the enumeration:

synchronous_replication_mode = off | recv | fsync | replay

This also looks a bit like the "synchronous_replication = N # similar in 
name to synchronous_commit" Simon Riggs proposed in 
http://archives.postgresql.org/pgsql-hackers/2010-05/msg01418.php

regards,
Yeb Havinga



PS: Please bear with me, I thought a bit about a way to make clear what 
deduction users must make when figuring out if the replication mode is 
synchronous. That question might be important when counting 'which 
servers are the synchronous standbys' to debug quorum settings.

replication_mode

from the assumption !async -> sync
and !async -> recv|fsync|replay
to infer recv|fsync|replay -> synchronous_replication.

synchronous_replication_mode

from the assumption !off -> on
and !off -> recv|fsync|replay
to infer recv|fsync|replay -> synchronous_replication.

I think the last one is easier made by humans, since everybody will make 
the !off-> on assumption, but not the !async -> sync without having that 
verified in the documentation.


In response to

Responses

pgsql-hackers by date

Next:From: Yeb HavingaDate: 2010-07-27 09:11:44
Subject: Re: Synchronous replication
Previous:From: Fujii MasaoDate: 2010-07-27 06:33:46
Subject: Re: [COMMITTERS] pgsql: Add restart_after_crash GUC.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group