murphy pope <pope_murphy@hotmail.com> writes:
> I don't get it. Why would database access fail during an aborted
> transaction?
Because we've already aborted the transaction (released its locks,
for instance). In a real sense you don't have a transaction at all
anymore.
> Can anyone explain? I've done some simple testing (just out of
> curiosity) but I can't seem to get anything to break if I always force
> IsAbortedTransactionBlockState() to return false.
IIRC the symptoms are relatively subtle. You might find locks that
never get released, for example. Or maybe it was locks that don't
get honored. Consider the following:
begin;select * from foo; -- takes an AccessShare on fooselect 1/0; -- abort, releases txn's locksselect *
fromfoo;
If we allowed parse analysis to run on the third select, it would need
to take out an AccessShare on foo (mainly to forestall the possibility
of someone dropping the table or altering its schema while we are
looking at it). Now suppose someone else actually does try to drop or
alter foo concurrently with the third select. There are two
possibilities:
1. The aborted transaction is still able to block the other guy.
2. The aborted transaction is not able to block the other guy, and soon crashes because the table schema is changing
underit.
Neither of these are appealing. I forget which way the lock code
actually behaves at the moment, but it's very possible that it's #2,
because the aborted transaction is not going to be seen as running
anymore.
The comment you are looking at is of relatively recent vintage ---
we went for a long time without recognizing the risks here.
regards, tom lane
