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

From Hiroshi Inoue
Subject Re: 2-phase commit
Date
Msg-id 3F77A2CF.D7543F1C@tpf.co.jp
Whole thread Raw
In response to Re: 2-phase commit  ("Hiroshi Inoue" <inoue@tpf.co.jp>)
Responses Re: 2-phase commit
Re: 2-phase commit
List pgsql-hackers
Hiroshi Inoue wrote:
> 
> > -----Original Message-----
> > From: Tom Lane
> >
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > Tom Lane wrote:
> > >> You're not considering the possibility of a transient communication
> > >> failure.
> >
> > > Can't the master re-send the request after a timeout?
> >
> > Not "it can", but "it has to".
> 
> Why ? Mainly the coordinator(slave) not the participant(master)
> has the resposibilty to resolve the in-doubt transaction.

As far as I see, it's the above point which prevents the
advance of this topic and the issue must be solved ASAP.

As opposed to your answer  Not "it can", but "it has to",
my answer is  Yes "it can", but "it doesn't have to".

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)'sTM.  3) resend the "commit requeset" to the participant's TM. 1)2)3) would be repeated until the
coordinatorreceives the "commit ok" message from the partcipant.
 

If there's no objection from you, I would assume I'm right.
Please don't dodge my question this time.

regards,
Hiroshi Inouehttp://www.geocities.jp/inocchichichi/psqlodbc/


pgsql-hackers by date:

Previous
From: Christopher Kings-Lynne
Date:
Subject: Re: pg_dump bug in 7.4
Next
From: Bruce Momjian
Date:
Subject: Re: pg_dump bug in 7.4