| From: | David Garamond <lists(at)zara(dot)6(dot)isreserved(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Two-phase commit issues |
| Date: | 2005-05-21 00:54:56 |
| Message-ID: | 428E86E0.6000607@zara.6.isreserved.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> [ Shrug... ] I remain of the opinion that 2PC is a solution in search
> of a problem, because it does not solve the single point of failure
> issue (just moves same from the database to the 2PC controller).
> But some people want it anyway, and they aren't going to be satisfied
> that we are an "enterprise grade" database until we can check off this
> particular bullet point. As long as the implementation doesn't impose
> any significant costs when not being used (which AFAICS Heikki's method
> doesn't), I think we gotta hold our noses and do it.
I thought the primary reason for having 2PC is to be able to participate
in a heterogenous transaction, e.g. with a non-Postgres database/other
types of resource managers? 2PC is mostly about how to make these
cross-RM transactions [appear] atomic. Redundancy is not covered by 2PC
protocol.
--
dave
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Neil Conway | 2005-05-21 01:01:53 | Re: patches for items from TODO list |
| Previous Message | Ed L. | 2005-05-20 21:54:28 | Re: [GENERAL] Image storage questions |