Hi,
After having published the source code, I'd like to add some words about
the current state of the project.
Postgres-R is currently capable of replicating tuples via binary change
sets, does proper conflict detection and prevention. It offers three
different timing methods: sync, eager and lazy. Out of those, the eager
method is the most advanced one, which I've been focusing on. However,
for fully synchronous replication, we mainly need to be able to handle
multiple changesets per transaction. This will be necessary anyway to
support long running transactions. Because it simply doesn't make sense
to keep a huge changeset back and send it just before the commit.
A pretty general framework for helper processes is provided. I think
this framework could be used for parallel querying or data loading as
well. The helper processes are ordinary backends which process a single
transaction at a time. But they don't have a client connection, instead
they communicate with a manager via a messaging module based on shared
memory and signals. Within Postgres-R, those helper backends are mostly
called 'remote backends', which is a somewhat misleading name. It's just
a short name for a helper backend which processes a remote transaction.
I've written interfaces to ensemble, spread and an emulated GCS for
testing purposes. The spread interface is still lacking functionality,
the other two should work fine. None of the interfaces is dependent on
external libraries, because I have added asynchronous clients, which
none of the given libraries for ensemble or spread offered, but is
required for the replication manager.
Sequence increments are replicated just fine and sequences feature an
additional per-node cache. The setval() functionality is still missing,
though.
Recovery and initialization must still be done manually, although I've
already done much of the work to synchronize table data. A daunting task
will be the synchronization of the sytsem catalogs. Postgres-R can
currently not replicate any DDL command.
Compared with the WAL log shipping method mentioned in the core team
statement about built-in replication, this is certainly the longer way
to go. But on the other hand it isn't limited to single-master
replication and certainly offers more options for future extensions.
Regards
Markus
