Re: 2-phase commit
Richard Huxton <dev@archonet.com>
From: Richard Huxton <dev@archonet.com>
To: Tom Lane <tgl@sss.pgh.pa.us>, Christopher Kings-Lynne <chriskl@familyhealth.com.au>
Cc: Bruce Momjian <pgman@candle.pha.pa.us>, Zeugswetter Andreas SB SD <ZeugswetterA@spardat.at>, Andrew Sullivan <andrew@libertyrms.info>, pgsql-hackers@postgresql.org
Date: 2003-09-27T09:34:34Z
Lists: pgsql-hackers
On Saturday 27 September 2003 06:59, Tom Lane wrote: > Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes: > >> ... You can make this work, but the resource costs > >> are steep. > > > > So, after 'n' seconds of waiting, we abandon the slave and the slave > > abandons the master. > > [itch...] But you surely cannot guarantee that the slave and the master > time out at exactly the same femtosecond. What happens when the comm > link comes back online just when one has timed out and the other not? > (Hint: in either order, it ain't good. Double plus ungood if, say, the > comm link manages to deliver the master's "commit confirm" message a > little bit after the master has timed out and decided to abort after all.) > > In my book, timeout-based solutions to this kind of problem are certain > disasters. I might be (well, am actually) a bit out of my depth here, but surely what happens is if you have machines A,B,C and *any* of them thinks machine C has a problem then it does. If C can still communicate with the others then it is told to reinitialise/go away/start the sirens. If C can't communicate then it's all a bit academic. Granted, if you have intermittent problems on a link and set your timeouts badly then you'll have a very brittle system, but if A thinks C has died, you can't just reverse that decision. -- Richard Huxton Archonet Ltd