On Tue, Jul 10, 2012 at 12:57 PM, Josh Berkus <j...@agliodbs.com> wrote: > Per your exchange with Heikki, that's not actually how SyncRep works in > 9.1. So it's not giving you what you want anyway. > > This is why we felt that the "sync rep if you can" mode was useless and > didn't accept it into 9.1. The *only* difference between sync rep and > async rep is whether or not the master waits for ack that the standby > has written to log. > > I think one of the new modes in 9.2 forces synch-to-DB before ack. No?
No. Such a mode has been discussed and draft patches have been circulated, but nothing's been committed. The new mode in 9.2 is less synchronous than the previous mode (wait for remote write rather than remote fsync), not more. Now, if we DID have such a mode, then many people would likely attempt to use synchronous replication in that mode as a way of ensuring that read queries can't see stale data, rather than as a method of providing increased durability. And in that case it sure seems like it would be useful to wait only if the standby is connected. In fact, you'd almost certainly want to have multiple standbys running synchronously, and have the ability to wait for only those connected at the moment. You might also want to have a way for standbys that lose their connection to the master to refuse to take any new snapshots until the slave is reconnected and has caught up. Then you could guarantee that any query run on the slave will see all the commits that are visible on the master (and possibly more, since commits become visible on the slave first), which would be useful for many applications. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
