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(at)libertyrms(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073