Consider this sequence of commands:
create type rowtype as (c int, d int);
create temp table t of rowtype;
\c -
drop type rowtype cascade;
Since the switch to MVCC catalog scans, it exhibits the following error about
10% of the time on my system:
CREATE TYPE
CREATE TABLE
You are now connected to database "test" as user "nm".
ERROR: XX000: cache lookup failed for relation 17009
LOCATION: getRelationDescription, objectaddress.c:2186
With "\c", in general, you may end up executing commands under the new session
before the old backend has finished exiting. For this test case specifically,
the two backends' attempts to drop table "t" regularly overlap. The old
backend would drop it within RemoveTempRelationsCallback(), and the new
backend would cascade from "rowtype" to drop it. findDependentObjects() deals
with concurrent deletion attempts by acquiring a lock on each object it will
delete, then calling systable_recheck_tuple() to determine whether another
deleter was successful while the current backend was waiting for the lock.
systable_recheck_tuple() uses the scan snapshot, which really only works if
that snapshot is SnapshotNow or some other that changes its decision in
response to concurrent transaction commits. The switch to MVCC snapshots left
this mutual exclusion protocol ineffective.
Let's fix this by having systable_recheck_tuple() acquire a fresh catalog MVCC
snapshot and recheck against that. I believe it would also be fully safe to
use SnapshotNow here; however, I'm assuming we would otherwise manage to
remove SnapshotNow entirely.
Thanks,
nm
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
