Обсуждение: Dumb question about parser vs. parse analyzer

At the top of backend/parser/gram.y there's a big comment that says "don't do any database access during the parse
phase,just in case we're in the middle of an aborted transaction".<br /><br /> I don't get it.  Why would database
accessfail during an aborted transaction?  Any changes have to be thrown away at the end of the transaction anyway,
right? Or is it that changes are invalidated as soon as an error occurs?  Is the parser just trying to avoid
per-statementtriggers after an error occurs?<br /><br /> Can anyone explain?  I've done some simple testing (just out
ofcuriosity) but I can't seem to get anything to break if I always force IsAbortedTransactionBlockState() to return
false.<br/><br /> TIA.<br /><br />          -- Murphy  

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