On Fri, Mar 18, 2011 at 3:41 PM, Markus Wanner <mar...@bluegap.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. Even with just a single server postgresql cluster, other clients(backends) can see the commit before the commiting client receives the ACK. Just that on a single server, the time period for that is small. Sync rep increases that time period by the length of time from when the slave reaches the commit point in the WAL stream to when it's ack of that point get's back to the wal sender. Ideally, that ACK time is small. Adding another round trip in there just for a "go almost to $COMIT, ok, now go to $COMMIT" type of WAL/ack is going to be pessimal for performance, and still not improve the *guarentees* it can make. It can only slightly reduce, but not eliminated that window where them master has WAL that the slave doesn't, and without a complete elimination (where you just switch the problem to be the slave has the data that the master doesn't), you haven't changed any of the guarantees sync rep can make (or not). a. -- Aidan Van Dyk Create like a god, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers