From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Two-phase commit |
Date: | 2004-02-09 20:09:34 |
Message-ID: | Pine.OSF.4.58.0402092201460.226205@kosh.hut.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
On Sun, 8 Feb 2004, Jeroen T. Vermeulen wrote:
> On Wed, Feb 04, 2004 at 10:22:16PM +0200, Heikki Linnakangas wrote:
>
> > There is a system view pg_prepared_xacts that gives you all transactions
> > that are in prepared state waiting for COMMITPREPARED or ABORTPREPARED.
>
> Great to hear that you've gotten so far with this... One question: can I
> check for this view to see if 2PC is supported before issuing the new
> kind of commit? I'm interested in supporting 2PC even for some regular
> transactions to reduce their in-doubt window, but I don't want to issue a
> command at the last moment that may fail (and thereby abort) because the
> backend version I'm connected to doesn't support the new command!
Yes, I suppose that would work. Though you would have to use a query that
wouldn't fail in case the view doesn't exist, otherwise you end up
aborting the transaction anyway. This should work:
SELECT COUNT(*) FROM pg_views WHERE schemanem='pg_catalog' AND viewname
='pg_prepared_xacts'
If it returns 1, you can do 2PC, if it returns 0, you have to regular
commit.
However, if this gets into 7.5, I guess you could just check for the
version of the backend instead with "SELECT version()".
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2004-02-09 20:41:07 | Re: [pgsql-hackers-win32] Sync vs. fsync during checkpoint |
Previous Message | Tom Lane | 2004-02-09 20:01:21 | Re: psql variables |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-02-09 20:45:54 | Re: win32 inode fix |
Previous Message | Neil Conway | 2004-02-09 17:44:26 | Re: win32 inode fix |