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

I don't get it.  Why would database access fail 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-statement triggers after an error occurs?

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.

TIA.

         -- Murphy







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

I don't get it.  Why would database access fail 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-statement triggers after an error occurs?

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.

TIA.

         -- Murphy
Mon, 19 Jul 2004 17:41:30 -0400
murphy pope <pope_murphy@hotmail.com>
Dumb question about parser vs. parse analyzer
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 foo
	select 1/0;		-- abort, releases txn's locks
	select * from foo;

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

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

Sun, 25 Jul 2004 16:10:51 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Dumb question about parser vs. parse analyzer 