Re: 2-phase commit

I haven't seen any comment on this email.

From our previous discussion of 2-phase commit, there was concern that
the failure modes of 2-phase commit were not solvable.  However, I think
multi-master replication is going to have similar non-solvable failure
modes, yet people still want multi-master replication.

We have had several requests for 2-phase commit in the past month.  I
think we should encourage the Japanese group to continue on their
2-phase commit patch to be included in 7.5.  Yes, it will have
non-solvable failure modes, but let's discuss them and find an
appropriate way to deal with the failures.

---------------------------------------------------------------------------

Andrew Sullivan wrote:
> Hi,
> 
> As the 7.4 beta rolls on, I thought now would be a good time to start
> talking about the future.  
> 
> I have a potential need in the future for distributed transactions
> (XA).  To get that from Postgres, I'd need two-phase commit, I think. 
> There is someone working on such a project
> (<http://snaga.org/pgsql/>), but last time it was discussed here, it
> received a rather lukewarm reception (see, e.g., the thread starting
> at
> <http://archives.postgresql.org/pgsql-hackers/2003-06/msg00752.php>).
> 
> While at OSCON, I had a discussion with Joe Conway, Bruce Momjian,
> and Greg Sabino Mullane about 2PC.  Various people expressed various
> opinions on the topic, but I think we agreed on the following.  The
> relevant folks can correct me if I'm wrong:
> 
> Two-phase commit has theoretical problems, but it is implemented in
> several "enterprise" RDBMS.  2PC is something needed by certain kinds
> of clients (especially those with transaction managers), so if
> PostgreSQL doesn't have it, PostgreSQL just won't get supported in
> that arena.  Someone is already working on 2PC, but may feel unwanted
> due to the reactions last heard on the topic, and may not continue
> working unless he gets some support.  What is a necessary condition
> for such support is to get some idea of what compromises 2PC might
> impose, and thereafter to try to determine which such compromises, if
> any, are acceptable ones.
> 
> I think the idea here is that, while in most cases a "pretty-good"
> implementation of a desirable feature might get included in the
> source on the grounds that it can always be improved upon later,
> something like 2PC has the potential to do great harm to an otherwise
> reliable transaction manager.  So the arguments about what to do need
> to be aired in advance. 
> 
> I (perhaps foolishly) volunteered to undertake to collect the
> arguments in various directions, on the grounds that I can contribute
> no code, but have skin made of asbestos.  I thought I'd try to
> collect some information about what people think the problems and
> potentially acceptable compromises are, to see if there is some way
> to understand what can and cannot be contemplated for 2PC.  I'll
> include in any such outline the remarks found in the -hackers thread
> referenced above.  Any objections?
> 
> A
> 
> -- 
> ----
> Andrew Sullivan                         204-4141 Yonge Street
> Liberty RMS                           Toronto, Ontario Canada
> <andrew@libertyrms.info>                              M2P 2A8
>                                          +1 416 646 3304 x110
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
> 
>                http://archives.postgresql.org
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073