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.
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/8de3e410faa06ab20ec1aa6d0abb0a2c040261ba
Modified Files
--------------
src/backend/utils/cache/relcache.c | 46 ++++++++++++++++++++++------
src/test/regress/expected/transactions.out | 14 +++++++++
src/test/regress/sql/transactions.sql | 19 ++++++++++++
3 files changed, 69 insertions(+), 10 deletions(-)
