Re: Synchronous replication

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Yeb Havinga <yebhavinga(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 11:42:44
Message-ID: AANLkTi=wOf6SjdOEscBCMqkMr7zhXcCk+pfQZj-433Ax@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 27, 2010 at 5:42 PM, Yeb Havinga <yebhavinga(at)gmail(dot)com> wrote:
> 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

ISTM that we need to get more feedback from users to determine which
is the best. So, how about leaving the parameter as it is and revisiting
this topic later? Since it's not difficult to change the parameter later,
we will not regret even if we delay that determination.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Yeb Havinga 2010-07-27 11:48:52 Re: Synchronous replication
Previous Message Fujii Masao 2010-07-27 11:29:29 Re: Synchronous replication