Re: triggers on prepare, commit, rollback... ?

>> I'm not claiming this is easy, on the contrary, but ISTM that the 2PC
>> semantics is all what is fundamentaly needed to achieve synchroneous
>> replication
>
> There are probably easier solutions for achieving this, like using two
> connections at client level

Sure, but that means doing the implementation in the client, although I
think that a system solution is better and independent of the client code,
and I may make the solution evolve in time without direct client-side
effect.

So I'm more interested in the generic implementation.

> or doing async replication,

The problem of Async is the *A*, you cannot guarantee that the data will
not be lost if the failure occurs between the commit and the later
replication. For some application, this is not an option.

> or running data modifications through pl/proxy functions where
> partitioning function always returns two partitions

I don't think that pl/proxy takes care of 2PC semantics in any useful way.

Possibly something like pgpool could take care somehow of the replication
by executing queries on two backends, but there are issues with such an
approach (say, a SEQUENCE may not return the same result on both sides,
some functions may have side effects...), and on commit it must use
prepared statements on both sides, and I don't think this is the case
for now with the current pgpool.

Anyway, I do not think that there is a simple high availability / high
throuput / low latency / guaranteed replication / easy to administrate /
load balanced silver bullet... My point is more about exploration, and
for that user-visible hooks would help.

--
Fabien.