From: | Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: psycopg and two phase commit |
Date: | 2010-09-19 21:49:28 |
Message-ID: | AANLkTimV0tH6Nq-PBcDPKK=jrE=6pZBtGnDx13xXinKv@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Sep 19, 2010 at 6:38 PM, Daniele Varrazzo
<daniele(dot)varrazzo(at)gmail(dot)com> wrote:
> On Sat, Sep 18, 2010 at 5:01 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>> There are some bariers?
>
> I see none at a first glance. I just don't get the intricacies of the
> .xid() method suggested in the dbapi
> (http://www.python.org/dev/peps/pep-0249/) while a regular string
> would do - and the xid has to be converted in a string anyway to be
> passed to the Postgres TPC statements. So I'm tempted to allow the
> tpc_*() methods to accept a simple string too as parameter; also
> because otherwise psycopg wouldn't be able to manipulate a transaction
> prepared by other tools (e.g. retrieving a xid using tpc_recover() and
> passing it to tpc_commit()/tpc_rollback(), a limitation that can be
> avoided.
I've read the XA specification, which have inspired the DBAPI
extension for TPC, and the discussion in the Python DB-SIG leading to
such extensions
(http://mail.python.org/pipermail/db-sig/2008-January/thread.html)
The methods proposed in the DBAPI don't map 1-1 with the PG TPC
statements so it will be necessary some work in the driver to
implement the proposed interface. But being TPC all about
interoperability I think it is a necessary complication.
-- Daniele
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2010-09-20 02:31:52 | Re: Configuring synchronous replication |
Previous Message | Tom Lane | 2010-09-19 21:36:57 | Re: pgxs docdir question |