Hi, Simon Riggs <si...@2ndquadrant.com> writes: > 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. >> >> This may be an incredibly naive question, but what happens to the >> transaction on the master if the number of confirmations is not >> received? > > 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. [...] > So whatever we do, we need additional parameters to specify timeouts > (including wait-forever as an option) and action-on-timeout: commit or > rollback.
I was preparing an email on the line that we need each slave to declare its desired minimum level of synchronicity, and have the master filter that with what the transaction wants. Scratch that. Thinking about it some more, I see that Simon's proposal is both more simple and effective: we already have Hot Standby and admin functions that tells us the last replayed LSN. The bigger wins. So in case of failover we know which slave to choose. The only use case I can see for what I had in mind is to allow the user to choose which server is trusted to have accurate data or better read only performances. But if the link is slow, the code will soon enough notice, mind you. I'm still not sure about my preference here, but I can see why Simon's proposal is simpler and addresses all concerns apart from forcing the servers into a non-optimal setup for a gain that is uneasy to see. Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers