Re: Transaction-controlled robustness for replication

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