On Tue, Jul 10, 2012 at 12:57 PM, Josh Berkus <josh@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
