Why would you spent time on implementing a mechanism whose ultimate benefit is supposed to be increasing reliability and performance, when you already realize that it will have to lock up at the slightest sight of trouble? There are better mechanisms out there that you can use instead.
If you want cross-server transactions, what other methods are there that are more reliable? It seems network unreliability is going to be a problem no matter what method you use.
I guess we need something like PITR to make this work because otherwise I cannot see a way to get in sync again.
Maybe I should call the desired mechanism "Entire cluster back to transaction X recovery".
Did anybody hear about PITR recently?
How else would you recover from any kind of problem?
No matter what you are doing network reliability will be a problem so we have to live with it.
Having some "going back to something consistent" is necessary anyway.
People might argue now that committed transactions might be lost. If people knew which ones, its ok. 90% of all people will understand that in case of a crash something evil might happen.
Hans
-- Cybertec Geschwinde u Schoenig Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria Tel: +43/2952/30706 or +43/660/816 40 77 www.cybertec.at, www.postgresql.at, kernel.cybertec.at
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
