Re: In-doubt window

On Mon, Oct 20, 2003 at 12:18:44PM -0400, Tom Lane wrote:

> 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:

Does this mean there's already a record in the database that (exists &&
is locked) if and only if the transaction is still in progress? Dirty
implementation details aside, that would be simple enough--sounds like
just what I need.

If only I gain the ability to see if the transaction is still in
progress, I can just patch that into my existing implementation to
close the hole. Anything else is optimization!

BTW, I guess I'd need to either create or update the record inside the
main transaction to get a useful XID on it, right?

> 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

It may be very postgres-specific but it's not really all that messy.
At least not if I structure my code right. C++ exceptions make it very
easy to "drop out of the algorithm" at any stage to convey the message
that the transaction failed. Which isn't even bad news under the
circumstances; the only bad news is no news.

And something I really like about your algorithm is that there's no
inconclusive exit. That's the important thing.

> 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.

We discussed that with Bruce at the FOSDEM last February... But if I
can do it without API and FE/BE protocol changes, barring any major
performance difference in the normal case, that's obviously better.

Might be a useful test vehicle as well. If we end up with something
that works but only leaves some garbage collection task that the client
isn't really the right place for, there's no need to make highly
specific changes to the core just to support one algorithm. Something
like the "active notification" Bruce came up with recently might do the
trick. Or maybe we'd want a "kill" feature similar to the Unix command
to force an abort onto an ongoing transaction. That way we could force
Schroedinger's cat to be either dead or alive, so to speak.

Thanks for your help BTW.

Jeroen