]> granicus.if.org Git - postgresql/commit
In RelationClearRelation, postpone cache reload if !IsTransactionState().
authorTom Lane <tgl@sss.pgh.pa.us>
Fri, 7 Feb 2014 00:37:58 +0000 (19:37 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 7 Feb 2014 00:38:06 +0000 (19:38 -0500)
commit8de3e410faa06ab20ec1aa6d0abb0a2c040261ba
tree167ce5bfe4dbfd97d4b6ed27683feeaf75c0c8b6
parent45e1b6c4c490a173208f98f4babc03b8fc69439e
In RelationClearRelation, postpone cache reload if !IsTransactionState().

We may process relcache flush requests during transaction startup or
shutdown.  In general it's not terribly safe to do catalog access at those
times, so the code's habit of trying to immediately revalidate unflushable
relcache entries is risky.  Although there are no field trouble reports
that are positively traceable to this, we have been able to demonstrate
failure of the assertions recently added in RelationIdGetRelation() and
SearchCatCache().  On the other hand, it seems safe to just postpone
revalidation of the cache entry until we're inside a valid transaction.
The one case where this is questionable is where we're exiting a
subtransaction and the outer transaction is holding the relcache entry open
--- but if we made any significant changes to the rel inside such a
subtransaction, we've got problems anyway.  There are mechanisms in place
to prevent that (to wit, locks for cross-session cases and
CheckTableNotInUse() for intra-session cases), so let's trust to those
mechanisms to keep us out of trouble.
src/backend/utils/cache/relcache.c
src/test/regress/expected/transactions.out
src/test/regress/sql/transactions.sql