Re: Two-phase commit

On Sat, 7 Feb 2004, Bruce Momjian wrote:

> > Please have a look and comment, the patches can be found here:
> > http://www.iki.fi/hlinnaka/pgsql/
> >
> > What is the schedule for 7.5? Any chance of getting this in?
>
> 7.5 is certainly possible. We are months away from beta on 7.5 and I
> would like ot see two-phase commit included. One item that has come up
> in past discussions is a way of recording two-phase commit failures to
> the administrator in cases where you precommit, get a reply, commit,
> then the remote machine disappears.

You would resolve this by opening a new session, and checking if the gid
you specified in PREPARE TRANSACTION is still present in the
pg_prepared_xacts view. It could be done manually by the administrator, or
it could be done automatically by an external transaction manager if
there is one.

The XA interface specifies a function called "recover", that gives you a
list of pending transactions. If we some day have an XA implementation,
the recover call would map directly to "SELECT gid FROM
pg_prepared_xacts". The JDBC XA implementation that I'm working on does
that already.

I have updated my patches, see the URL above. I renamed the commands to
PREPARE TRANSACTION, COMMIT PREPARED and ROLLBACK PREPARED. I think it's
more coherent that way.

I also added documentation entries for the commands, and a basic
regression test.

I went through all the AtCommit_* and AtEOXact* hooks in xact.c to find
any possible problem areas. The following items have not yet been
implemented and throw an error if you try to do 2PC in the same
transaction.

* Notifications (NOTIFY/LISTEN). All pending notifications should be
stored in persistent storage in the prepare phase, and sent in the commit
phase.

* Creation/deletion of relations. I couldn't figure out how the relation
cache invalidation stuff should work with 2PC.

* Modifying GUC variables. I need to study the GUC code more thoroughly
before I can tell what needs to be done.

* Updates to shadow/group files, that is, CREATE USER and friends. Needs
some tricks to delay the writing of pg_pwd/pg_group.

* Large objects. AFAICS, no particular problem here, but I'd like to deal
with them later when the more important stuff are ok.

Plus a couple of minor details:

* Temporary tables. The seem to work somehow, but I haven't tested them
much. I have a feeling that nasty things might happen if you commit the
prepared transaction from another backend etc.

* initdb gives a warning about a missing file. It's harmless, but I
don't see how to detect that you're running under initdb. Also, if you
try to prapare a transaction with a global transaction identifier that's
already in use, you first get a warning and then an error.

I'm going to tackle the above problems later, but I would like to get
this applied to the cvs trunk with the current functionality first, after
discussion of course. The rest are nice to have for the sake of
completeness but probably not necessary for most users.

- Heikki