On Tue, 2008-05-20 at 12:09 +0200, Fabien COELHO wrote: > As for replication, I was naively thinking of using BEFORE PREPARE to > forward a prepare and possibly fail in the master if the slave fails, and > then an AFTER PREPARE or BEFORE COMMIT/ROLLBACK PREPARE would forward the > final COMMIT/ROLLBACK depending on the success of the prepare operation in > the master and slaves. The function could also wait for something to > finish on the slave. > > If the something fails in between, then there are several state > combinations to detect and handle, but this is just the point of 2PC. > > 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, and once hooks are available there should be a way to > prototype something at the user level (slony style). The efficiency of the > stuff is another issue, but some applications don't need high throughput > and low latency, but just to know that the data are not lost.
There are probably easier solutions for achieving this, like using two connections at client level or doing async replication, or running data modifications through pl/proxy functions where partitioning function always returns two partitions --------------- Hannu -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers