On 5/26/2010 12:55 PM, Heikki Linnakangas wrote:
On 26/05/10 18:31, Robert Haas wrote:
And frankly, I don't think it's possible for quorum commit to reduce
the number of parameters. Even if we have that feature available, not
everyone will want to use it. And the people who don't will
presumably need whatever parameters they would have needed if quorum
commit hadn't been available in the first place.
Agreed, quorum commit is not a panacea.
For example, suppose that you have two servers, master and a standby,
and you want transactions to be synchronously committed to both, so that
in the event of a meteor striking the master, you don't lose any
transactions that have been replied to the client as committed.
Now you want to set up a temporary replica of the master at a
development server, for testing purposes. If you set quorum to 2, your
development server becomes critical infrastructure, which is not what
you want. If you set quorum to 1, it also becomes critical
infrastructure, because it's possible that a transaction has been
replicated to the test server but not the real production standby, and a
meteor strikes.
Per-standby settings would let you express that, but not OTOH the quorum
behavior where you require N out of M to acknowledge the commit before
returning to client.
You can do this only with per standby options, by giving each standby a
weight, or a number of votes. Your DEV server would have a weight of
zero, while your production standby's have higher weights, depending on
their importance for your overall infrastructure. As long as majority
means >50% of all votes in the house, you don't have a split brain risk.
Jan
--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
