pgsql: In RelationClearRelation, postpone cache reload if !IsTransactio
От | Tom Lane |
---|---|
Тема | pgsql: In RelationClearRelation, postpone cache reload if !IsTransactio |
Дата | |
Msg-id | E1WBZSV-0000xp-4P@gemulon.postgresql.org обсуждение исходный текст |
Список | pgsql-committers |
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(-)
В списке pgsql-committers по дате отправления: