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
