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

Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Aidan Van Dyk <aidan(at)highrise(dot)ca>
Cc: Markus Wanner <markus(at)bluegap(dot)ch>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, MARK CALLAGHAN <mdcallag(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Date: 2011-03-22 20:33:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-committerspgsql-hackers
On Fri, Mar 18, 2011 at 5:08 PM, Aidan Van Dyk <aidan(at)highrise(dot)ca> wrote:
> On Fri, Mar 18, 2011 at 3:41 PM, Markus Wanner <markus(at)bluegap(dot)ch> wrote:
>> On 03/18/2011 08:29 PM, Simon Riggs wrote:
>>> We could do that easily enough, actually, if we wished.
>>> Do we wish?
>> I personally don't see any problem letting a standby show a snapshot
>> before the master.  I'd consider it unneeded network traffic.  But then
>> again, I'm completely biased.
> In fact, we *need* to have standbys show a snapshot before the master.
> By the time the master acks the commit to the client, the snapshot
> must be visible to all client connected to both the master and the
> syncronous slave.

We might have a version of synchronous replication that works this way
some day, but it's not the version were shipping with 9.1.  The slave
acknowledges the WAL records when they hit the disk (i.e. fsync) not
when they are applied; WAL apply can lag arbitrarily.  The point is to
guarantee clients that the WAL is on disk somewhere and that it will
be replayed in the event of a failover.  Despite the fact that this
doesn't work as you're describing, it's a useful feature in its own

Robert Haas
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2011-03-22 20:43:00
Subject: crash-safe visibility map, take four
Previous:From: Robert HaasDate: 2011-03-22 20:15:24
Subject: Re: Flex output missing from 9.1a4 tarballs?

pgsql-committers by date

Next:From: Tom LaneDate: 2011-03-22 20:55:48
Subject: pgsql: Improve reporting of run-time-detected indeterminate-collatione
Previous:From: Tom LaneDate: 2011-03-22 19:58:31
Subject: pgsql: Throw error for indeterminate collation of anORDER/GROUP/DISTIN

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