> > > > 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-->
This is the commit for phase 1. This commit is allowed to return all
sorts of errors, like violated deferred checks, out of diskspace, ...
> <--OK
> commit done->XX
This is commit for phase 2, the slave *must* answer with "success"
in all but hardware failure cases. (Note that instead the master could
instead send rollback, e.g. because some other slave aborted)
> is the "commit done" message needed ?
So, yes this is needed.
Andreas
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
