Re: XA support (distributed transactions)

From: "Dawid Kuroczko" <qnex42(at)gmail(dot)com>
To: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: XA support (distributed transactions)
Date: 2006-11-20 19:55:21
Message-ID: 758d5e7f0611201155j241874aw757ceab68e9d1974@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11/20/06, Florian G. Pflug <fgp(at)phlo(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Florian G. Pflug 2006-11-20 20:07:59 Re: XA support (distributed transactions)
Previous Message Josh Berkus 2006-11-20 19:29:08 Re: XA support (distributed transactions)