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
