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
<andrew@libertyrms.info> M2P 2A8 +1 416 646 3304
x110