On Tue, 2010-05-25 at 19:08 +0200, Alastair Turner wrote: > On Tue, May 25, 2010 at 6:28 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > ....... > > > > The best parameter we can specify is the number of servers that we wish > > to wait for confirmation from. That is a definition that easily manages > > the complexity of having various servers up/down at any one time. It > > also survives misconfiguration more easily, as well as providing a > > workaround if replicating across a bursty network where we can't > > guarantee response times, even of the typical response time is good. > > > > This may be an incredibly naive question, but what happens to the > transaction on the master if the number of confirmations is not > received? Is this intended to create a situation where the master > effectively becomes unavailable for write operations when its > synchronous slaves are unavailable?
How we handle degraded mode is important, yes. Whatever parameters we choose the problem will remain the same. Should we just ignore degraded mode and respond as if nothing bad had happened? Most people would say not. If we specify server1 = synch and server2 = async we then also need to specify what happens if server1 is down. People might often specify if (server1 == down) server2 = synch. So now we have 3 configuration settings, one quite complex. It's much easier to say you want to wait for N servers to respond, but don't care which they are. One parameter, simple and flexible. In both cases, we have to figure what to do if we can't get either server to respond. In replication there is no such thing as "server down" just a "server didn't reply in time X". So we need to define timeouts. So whatever we do, we need additional parameters to specify timeouts (including wait-forever as an option) and action-on-timeout: commit or rollback. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers