Andres Freund <andres@2ndquadrant.com> writes:
> On 2013-08-08 09:27:24 -0400, Robert Haas wrote:
>> How can it be safe to try to read catalogs if the transaction is aborted?
> Well. It isn't. At least not in general. The specific case triggered
> here though are cache invalidations being processed which can lead to
> the catalog being read (pretty crummy, but not easy to get rid
> of). That's actually safe since before we process the invalidations we
> have done:
> 1) CurrentTransactionState->state = TRANS_ABORT
> 2) RecordTransactionAbort(), marking the transaction as aborted in the
> clog
> 3) marked subxacts as aborted
> 3) ProcArrayEndTransaction() (for toplevel ones)
> Due to these any tqual stuff will treat the current (sub-)xact and it's
> children as aborted. So the catalog lookups will use the catalog in a
> sensible state.
I don't have any faith in this argument. You might be right that we'll
correctly see our own output rows as aborted, but that's barely the tip
of the iceberg of risk here. Is it safe to take new locks in an aborted
transaction? (What if we're already past the lock-release point in
the abort sequence?) For that matter, given that we don't know what
exactly caused the transaction abort, how safe is it to do anything at
all --- we might for instance be nearly out of memory. If the catalog
reading attempt itself fails, won't we be in an infinite loop of
transaction aborts? I could probably think of ten more risks if
I spent a few more minutes at it.
Cache invalidation during abort should *not* lead to any attempt to
immediately revalidate the cache. No amount of excuses will make that
okay. I have not looked to see just what the path of control is in this
particular case, but we need to fix it, not paper over it.
regards, tom lane
