On Fri, Mar 4, 2011 at 3:04 PM, Fujii Masao <masao.fu...@gmail.com> wrote: > The "wait-forever" might be a straightforward approach against (B). But > this option prevents transactions from running not only when the > synchronous standby goes away, but also when the primary is invoked > first or when the standby is promoted at failover. Since the availability > of the database service decreases very much, I don't want to use that.
I continue to think that wait-forever is the most sensible option. If you want all of your data on the disks of two machines before the commit is ack'd, I think you probably want that all the time. The second scenario you mentioned ("when the standby is promoted at failover") is quite easy to handle. If you don't want synchronous replication after a standby promotion, then configure the master to do synchronous replication and the slave not to do synchronous replication. Similarly, if you've got an existing machine that is not doing synchronous replication and you want to start, fire up the standby in asynchronous mode and switch to synchronous replication after it has fully caught up. It seems to me that we're bent on providing a service that does synchronous replication except when it first starts up or when the timeout expires or when the phase of the moon is waxing gibbons, and I don't get the point of that. If I ask for synchronous replication, I want it to be synchronous until I explicitly turn it off. Otherwise, when I fail over, how do I know if I've got all my transactions, or not? -- 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