Re: XA support (distributed transactions) - Mailing list pgsql-hackers

From Dawid Kuroczko
Subject Re: XA support (distributed transactions)
Date
Msg-id 758d5e7f0611201155j241874aw757ceab68e9d1974@mail.gmail.com
Whole thread Raw
In response to Re: XA support (distributed transactions)  ("Florian G. Pflug" <fgp@phlo.org>)
Responses Re: XA support (distributed transactions)
List pgsql-hackers
On 11/20/06, Florian G. Pflug <fgp@phlo.org> wrote:
> Danny Milosavljevic wrote:
> > Hi,
> >
> > We (Fabalabs) are looking into adding XA support (distributed
> > transactions) to Postgresql.
>
> Postgres already supports 2 phase commits, which is can basis
> on which XA can be implemented I think. The "only" missing
> part is an transaction manager, but that wouldn't have to
> be integrated into postgres. As far as I understand things,
> the only thing you really need the transaction manager for
> is for automatic recovery if one member of a distributed
> transaction fails while the transaction is still in progress.
> In that case the transaction manager needs to either rollback
> the transaction, if it wasn't already prepared on all nodes,
> or commit it.

Hmm, a bit not on topic, but how big is 2PC overhead in
PostgreSQL.  I mean, I have an application which could
benefit from 2PC but it is not mandatory -- it is connected
to two DBs, and the second transaction is committed
if first one succeeds.  There is virtually no chance that
the second commit won't succeed (rows are locked
for update and all transactions lock rows in same
order, etc, etc), but using 2PC would make a nice
warm feeling.  Then again, the process is quite
stressful for that DB so I want to push as little
overhead there as possible.
  Regards,      Dawid


pgsql-hackers by date:

Previous
From: "Florian G. Pflug"
Date:
Subject: Re: XA support (distributed transactions)
Next
From: "Florian G. Pflug"
Date:
Subject: Re: XA support (distributed transactions)