| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
| Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Zeugswetter Andreas SB SD <ZeugswetterA(at)spardat(dot)at>, Andrew Sullivan <andrew(at)libertyrms(dot)info>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: 2-phase commit |
| Date: | 2003-09-27 05:59:38 |
| Message-ID: | 1703.1064642378@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephan Szabo | 2003-09-27 06:05:48 | Re: invalid tid errors in latest 7.3.4 stable. |
| Previous Message | Oliver Elphick | 2003-09-27 05:55:49 | Re: initdb failure (was Re: [GENERAL] sequence's plpgsql) |