Re: 2-phase commit

Поиск
Список
Период
Сортировка
От Marc G. Fournier
Тема Re: 2-phase commit
Дата
Msg-id 20030929105527.D632@ganymede.hub.org
обсуждение исходный текст
Ответ на Re: 2-phase commit  (Hiroshi Inoue <Inoue@tpf.co.jp>)
Ответы Re: 2-phase commit  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers

On Mon, 29 Sep 2003, Hiroshi Inoue wrote:

>
>
> Hiroshi Inoue wrote:
> >
> > Tom Lane wrote:
> > >
> > > 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.
> >
> > Oops my mistake, sorry.
> > But is it 2-phase commit protocol in the first place ?
>
> That is, in your exmaple below
>
>  Example:
>
>         Master          Slave
>         ------          -----
>         commit ready-->
>                         <--OK
>         commit done->XX
>
> is the "commit done" message needed ?

Of course ... how else will the Slave commit?  From my understanding, the
concept is that the master sends a commit ready to the slave, but the OK
back is that "OK, I'm ready to commit whenever you are", at which point
the master does its commit and tells the slave to do its ...



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andreas Pflug
Дата:
Сообщение: Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta)
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: pg_dump bug in 7.4