On Thu, Oct 09, 2003 at 04:22:13PM +0200, Peter Eisentraut wrote: > 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.
"The slightest sign of trouble" seems to me to be overstating the matter rather. It cannot recover in the case where the first phase of commit has happened everywhere, and then the master crashes. We are talking, after all, about a pretty exotic feature in the first place. I presume that anyone who is using it is also using it on machines which have ultra-high-reliable, the cpu can catch on fire and the box stays up sort of hardware. I'll grant you that running a pair of B0b'5 C0mpu73r5 Ultra kewl sooper fa5t overclocked specials with serial ATA with the write cache enabled is a recipe for data loss. But that's a disaster no matter what. But you cannot have XA-like stuff without 2PC. You can't easily have heterogenous systems without 2PC. And folks have already generously volunteered to work on this problem; I think that they deserve support, assuming we can come up with some idea of what kinds of compromises are acceptable ones. There's no question that 2PC requires some unpleasant compromises. But if you want someone to be able to add a Postgres member to a heterogenous cluster, you're going to need to be able to accept some compromises, because the DBA (or, more likely, his management) already has. I'm not sure that 2PC is actually intended to increase reliability or performance, by the way. A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada <[EMAIL PROTECTED]> M2P 2A8 +1 416 646 3304 x110 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend