Re: 2-phase commit - Mailing list pgsql-hackers

From Tom Lane
Subject Re: 2-phase commit
Date
Msg-id 16664.1064809387@sss.pgh.pa.us
Whole thread Raw
In response to Re: 2-phase commit  (Hiroshi Inoue <Inoue@tpf.co.jp>)
Responses Re: 2-phase commit  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> The simplest senario(though there could be varations) is

> [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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta)
Next
From: Tom Lane
Date:
Subject: Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta)