Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> 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.
OK maybe I understand your complaint.
Basically such situation can occur when either side
is down. Especially when the coodinator(master) is down,
the particicipants are troubled. In such cases, e.g. XA
interface allows heuristic-commit on the participants.
In case one or more paricipants are down, the coordinator
may have to remember per-transaction state indefinitely.
Is it a big problem ?
regards,
Hiroshi Inoue
http://www.geocities.jp/inocchichichi/psqlodbc/
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
