From: | Markus Wanner <markus(at)bluegap(dot)ch> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Transaction-controlled robustness for replication |
Date: | 2008-07-22 21:35:01 |
Message-ID: | 48865285.4010209@bluegap.ch |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
very nice proposal and thoughts. Allow me to compare against Postgres-R
again.
Simon Riggs wrote:
> Asynchronous commit controls whether we go to disk at time of commit, or
> whether we defer this slightly. We have the same options with
> replication: do we replicate at time of commit, or do we defer this
> slightly for performance reasons. DRBD and other replication systems
> show us that there is actually another difference when talking about
> synchronous replication: do we go to disk on the standby before
> acknowledging the primary?
Yeah, I was thinking into the same direction for Postgres-R. There
already exist three replication levels: sync, eager and lazy.
Having more than just a primary and a standby server in mind, one can
also argue about how many remote nodes need to have written the changes
to disc, before commit is confirmed in 'sync' mode. At least a majority
is required, probably more nodes are wanted.
The eager mode is what the original Postgres-R approach is all about and
is pretty much the only one I've implemented, at the moment. It only
requires confirmation from the GCS, which means at least a majority of
the nodes have received the change set (and will be able to apply it).
(This leads to a corner case for a full cluster outage, see [1]).
In async mode, commit is confirmed before sending the change set to
other nodes.
> If we are able to define these robustness characteristics for each
> transaction *separately* then it will represent an industry first:
Yeah, that would be pretty cool.
> no
> other database has that capability implemented or planned on published
> roadmaps, nor has it been discussed in research to my knowledge.
Well, a partial implementation in Postgres-R, if that counts... ;-)
Regards
Markus
[1]: One of the few threads on the Postgres-R-general mailing list:
http://pgfoundry.org/pipermail/postgres-r-general/2006-August/000002.html
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-07-22 21:36:48 | Re: Do we really want to migrate plproxy and citext into PG core distribution? |
Previous Message | Decibel! | 2008-07-22 21:32:36 | Re: Postgres-R: tuple serialization |