From: | "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> |
---|---|
To: | "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org> |
Cc: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Andrew Sullivan" <andrew(at)libertyrms(dot)info>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: 2-phase commit |
Date: | 2003-09-29 14:41:11 |
Message-ID: | 46C15C39FEB2C44BA555E356FBCD6FA4962022@m0114.s-mxs.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > > 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 ...
>
> Or the slave could reject the request.
At this point only because of a hardware error. In case of network
problems the "commit done" eighter did not reach the slave or the "success"
answer did not reach the master.
That is what it's all about. Phase 2 is supposed to be low overhead and very
fast to allow keeping the time window for failure (that produces in-doubt
transactions) as short as possible.
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-09-29 14:45:57 | Re: 2-phase commit |
Previous Message | Zeugswetter Andreas SB SD | 2003-09-29 14:32:43 | Re: 2-phase commit |