Roadmap for Database Kernel XA Support - Mailing list pgsql-general

From Horst G. Reiterer
Subject Roadmap for Database Kernel XA Support
Date
Msg-id 010e01c4ee2d$f73919b0$896bf1d4@cm76172.liwest.at
Whole thread Raw
Responses Re: Roadmap for Database Kernel XA Support  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-general
Hi,

a native application of ours is based on distributed transactions and thus
requires all databases to provide an XA interface so that an XA-compliant
DTM (e.g. Tuxedo) can do its work.

I read in the JDBC driver FAQ (I'm not interested in the JDBC driver itself)
at http://jdbc.postgresql.org/documentation/faq.html that XA Support for the
database is scheduled for 8.1, does that still hold true (if yes, do you
have an early 8.1 ETA)?

From my understanding, supporting XA would mean to

  - provide an XA library implementing the XA interface
    as described in the X/Open XA specification at
    http://www.opengroup.org/publications/catalog/c193.htm

  - support commit preparation (the process of persisting
    transactional changes without actually committing the
    transaction so that a later commit is guaranteed to
    succeed should the log be available in a consistent
    state)

  - [optional] allow a Point-In-Time Recovery (PITR) based
    on an XA XID rather than an internal transaction id or
    time specification. This functionality would enable
    a consistent recovery of multiple, cooperating
    PostgreSQL databases.

Judging from a one day old CVS checkout, neither of these aspects have been
addressed at this time or are currently being worked on. If at all possible,
please provide me with an update on the current status and plan on
implementing XA support. Can you estimate the time (e.g. in man-days) and
implementation complexity of integrating this functionality?

Thanks in advance for any insights in this respect!

Cheers,

Horst.

P.S.: The 8.0 release candidate rocks, PITR works flawlessly, without a
hitch. Thanks for your efforts!


pgsql-general by date:

Previous
From: Eric Brown
Date:
Subject: Re: debug_print_plan (pg7.4) doesn't seem to do anything
Next
From: Greg Stark
Date:
Subject: Re: pg_dump and pgpool