On Fri, 2011-03-18 at 11:07 -0400, Robert Haas wrote: > On Fri, Mar 18, 2011 at 10:55 AM, Greg Stark <gsst...@mit.edu> wrote: > > On Thu, Mar 17, 2011 at 5:46 PM, Robert Haas <robertmh...@gmail.com> wrote: > >> What makes more sense to me after having thought about this more > >> carefully is to simply make a blanket rule that when > >> synchronous_replication=on, synchronous_commit has no effect. That is > >> easy to understand and document. > > > > For what it's worth "has no effect" doesn't make much sense to me. > > It's a boolean, either commits are going to block or they're not. > > > > What happened to the idea of a three-way switch? > > > > synchronous_commit = off > > synchronous_commit = disk > > synchronous_commit = replica > > > > With "on" being a synonym for "disk" for backwards compatibility. > > > > Then we could add more options later for more complex conditions like > > waiting for one server in each data centre or waiting for one of a > > certain set of servers ignoring the less reliable mirrors, etc. > > This is similar to what I suggested upthread, except that I suggested > on/local/off, with the default being on. That way if you set > synchronous_standby_names, you get synchronous replication without > changing another setting, but you can say local instead if for some > reason you want the middle behavior. If we're going to do it all with > one GUC, I think that way makes more sense. If you're running sync > rep, you might still have some transactions that you don't care about, > but that's what async commit is for. It's a funny kind of transaction > that we're OK with losing if we have a failover but we're not OK with > losing if we have a local crash from which we recover without failing > over.
I much prefer a single switch, which is what I originally suggested. Changing the meaning of synchronous_commit seems a problem. durability = localmemory durability = localdisk (durability = remotereceive - has no meaning in current code) durability = remotedisk durability = remoteapply it also allows us to have in the future -- Simon Riggs http://www.2ndQuadrant.com/books/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
