Re: [HACKERS] 2-phase commit

[Manfred Spraul]

Peter Eisentraut wrote:

Tom Lane writes:

 

No.  The real problem with 2PC in my mind is that its failure modes
occur *after* you have promised commit to one or more parties.  In
multi-master, if you fail you know it before you have told the client
his data is committed.
   

I have a book here which claims that the solution to the problems of
2-phase commit is 3-phase commit, which goes something like this:
coordinator             participant
-----------             -----------
INITIAL                 INITIAL
        prepare -->
WAIT
        <-- vote commit
                        READY
(all voted commit)
        prepare-to-commit -->
PRE-COMMIT
        <-- ready-to-commit
                        PRE-COMMIT
        global-commit -->
COMMIT                  COMMIT
If the coordinator fails and all participants are in state READY, they can
safely decide to abort after some timeout.  If some participant is already
in state PRE-COMMIT, it becomes the new coordinator and sends the
global-commit message.
Details are left as an exercise. :-)
 

Ok. Lets assume one coordinator, two partitipants.
Global commit send to both by coordinator. One replies with ok, the 
other one remains silent.
What should the coordinator do? It can't fail the transaction - the 
first partitipant has commited its part. It can't complete the 
transaction, because the ok from the 2nd partitipant is still outstanding.
I think Bruce is right: It's an admin decision. If a timeout expires, a 
user supplied app should be called, with a safe default (database 
shutdown?).

--
   Manfred
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster