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
The Enterprise PostgreSQL Company
In response to
pgsql-hackers by date
|Next:||From: Robert Haas||Date: 2011-03-22 20:43:00|
|Subject: crash-safe visibility map, take four|
|Previous:||From: Robert Haas||Date: 2011-03-22 20:15:24|
|Subject: Re: Flex output missing from 9.1a4 tarballs?|
pgsql-committers by date
|Next:||From: Tom Lane||Date: 2011-03-22 20:55:48|
|Subject: pgsql: Improve reporting of run-time-detected indeterminate-collatione|
|Previous:||From: Tom Lane||Date: 2011-03-22 19:58:31|
|Subject: pgsql: Throw error for indeterminate collation of anORDER/GROUP/DISTIN|