On Wed, 2010-04-28 at 22:17 +0200, Dimitri Fontaine wrote: > IMO the real fun begins when we talk about multi-slaves support and > their roles (a failover slave wants the master to wait for it to have > applied the WAL before to commit, a reporting slave not so much). So > you'd set the Availability level on each slave and wouldn't commit on > the master until each slave got what it's configured for, or something > like that.
Just for the record, I outlined desirable semantics for this on hackers in 2008 and want to keep those ideas on the table. http://archives.postgresql.org/pgsql-hackers/2008-07/msg01001.php My view is that it should be up to the master what happens on master. An additional standby connection should not have the ability to make transactions on the master wait. If we give control to the master rather than the standby, we are then able to allow transactions on the master choose how robust they should be, just as we do with synchronous_commit. IMHO that is extremely important, since we already know that sync rep performs poorly and applications need to mitigate that in some way. Those are the objectives, the parameters to do that are a different story and we might expect much debate. One way of doing this would be to have a parameter called synchronous_replication = N, which would cause the transaction on primary to wait for at least N standbys to reply that they have the data. This would allow settings like synchronous_commit = 0 --async synchronous_commit = 1 --first reply wins == max performance synchronous_commit = 2 --multiple replies needed == max availability ... -- 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