Subject: Re: Sync Rep Design
From: Simon Riggs <simon@2ndQuadrant.com>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Hannu Krosing <hannu@2ndquadrant.com>,
 Robert Haas <robertmhaas@gmail.com>,
	Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>,
	pgsql-hackers@postgresql.org
In-Reply-To: <4D1DAB14.5000800@enterprisedb.com>
References: <1293729972.1892.23804.camel@ebony>
	<4D1CC47E.7050207@kaltenbrunner.cc>	<1293735853.1892.24886.camel@ebony>
	<AANLkTi=SvN2KQ1Tzh-tRKcXD0i2FyWFBbbR=kXXdepqN@mail.gmail.com>
	<4D1D8B2F.5070001@2ndquadrant.com> <4D1DAB14.5000800@enterprisedb.com>
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 31 Dec 2010 10:42:15 +0000
Message-ID: <1293792135.1892.36442.camel@ebony>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Fri, 2010-12-31 at 12:06 +0200, Heikki Linnakangas wrote:
> On 31.12.2010 09:50, Hannu Krosing wrote:
> > On 30.12.2010 22:27, Robert Haas wrote:
> >> On Thu, Dec 30, 2010 at 2:04 PM, Simon Riggs<simon@2ndquadrant.com>
> >> wrote:
> >>> synchronous_replication (boolean)
> >>> Specifies whether transaction commit will wait for WAL records
> >>> to be replicated before the command returns a "success"
> >>> indication to the client.
> >> The word "replicated" here could be taken to mean different things,
> >> most obviously:
> >>
> >> - slave has received the WAL
> >> - slave has fsync'd the WAL
> >> - slave has applied the WAL
> > Perhaps the level of "replication guarantee" should be decided on the
> > slave side, by
> > having a configuration parameter there
> >
> > report_as_replicated = received|written_to_disk|fsynced|applied
> >
> > for different types of hosts may have wildly different guarantees and
> > performance
> > parameters for these. One could envision a WAL-archive type "standby"
> > which is
> > there for data persistence only will and never "apply" WAL.
> 
> Agreed, it feels natural to specify when a piece of WAL is acknowledged 
> in the standby.

That can also be done, its not a problem.

Many people asked for just "on" or "off".

Currently "on" <--> "slave has fsynced" WAL.

> Also, I dislike the idea of having the standby 
> specify that it's a synchronous standby that the master has to wait for. 
> Behavior on the master should be configured on the master.

The parameter on the standby affects the behaviour of the standby. The
standby is saying "don't pick me, I'm not a good target".

-- 
 Simon Riggs           http://www.2ndQuadrant.com/books/
 PostgreSQL Development, 24x7 Support, Training and Services