Tom Lane wrote:
> > [At participant(master)'s side]
> > Because the commit operations is done, does nothing.
>
> > [At coordinator(slave)' side]
> > 1) After a while
> > 2) re-establish the communication path between the
> > partcipant(master)'s TM.
> > 3) resend the "commit requeset" to the participant's TM.
> > 1)2)3) would be repeated until the coordinator receives
> > the "commit ok" message from the partcipant.
>
> [ scratches head ] I think you are using the terms "master" and "slave"
> oppositely than I would. But in any case, this is not an answer to the
> concern I had. You're assuming that the "coordinator(slave)" side is
> willing to resend a request indefinitely, and also that the
> "participant(master)" side is willing to retain per-transaction commit
> state indefinitely so that it can correctly answer belated questions
> from the other side. What I was complaining about was that I don't
> think either side can afford to remember per-transaction state
> indefinitely. 2PC in the abstract is a useless academic abstraction ---
> where the rubber meets the road is defining how you cope with failures
> in the commit protocol.
I don't think there is any way to handle cases where the master or slave
just disappears. The other machine isn't under the server's control, so
it has no way of it knowing. I think we have to allow the administrator
to set a timeout, or ask to wait indefinately, and allow them to call an
external program to record the event or notify administrators.
Multi-master replication has the same issues.
My original point was that multi-master replication has the same
limitations, but people still want it. Same for two-phase commit --- it
has the same limitations, but people want it.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073