From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: In-doubt window |
Date: | 2003-10-20 16:18:44 |
Message-ID: | 3220.1066666724@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Jeroen T. Vermeulen" <jtv(at)xs4all(dot)nl> writes:
> Some of you may remember that we discussed libpqxx's higher-level
> support for transactionality.
> [complicated scheme]
Another way you can look to see if a transaction has completed is to see
if there is still an ExclusiveLock record for it in pg_locks. For this
you need to know the transaction's internal XID, but you can get that
from the XMAX of the log record it deleted. In other words:
insert log record;
begin;
delete log record;
<<payload work>>
commit;
On reconnect:
log record not present: it committed
else, read XMAX from log record
zero -> failed before the delete :-(
not zero -> look for match in pg_locks
found -> transaction still in progress, wait
not found -> it aborted
This is all pretty messy though. Seems like it would be a whole lot
easier if the backend exposed ways to (a) obtain your current
transaction number and (b) inquire directly about the commit status of
a transaction. However, with the present transaction infrastructure
(b) would only work for a limited time window after the original
transaction (until the corresponding clog space got recycled). So that
might or might not be good enough for your purposes.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2003-10-20 16:25:29 | Re: Vacuum thoughts |
Previous Message | Marc G. Fournier | 2003-10-20 16:13:05 | Looks like we'll have a beta5 ... |