I wrote:
> This explanation is nonsense; we certainly *are* holding a lock on any
> relation that's about to be dropped. Experimentation shows that
> AccessExclusiveLock is indeed held (you can see it in pg_locks), but
> nonetheless the PREPARE doesn't complain. Did you trace through
> exactly why?
I looked into this, and the problem is in LockTagIsTemp: it checks
whether a lock is on a temp table this way:
if (isTempOrToastNamespace(get_rel_namespace((Oid) tag->locktag_field2))) return true;
What is happening is that get_rel_namespace fails to find the syscache
entry for the table's pg_class row (which is expected since it's already
been deleted as far as this transaction is concerned). It silently
returns InvalidOid, and then isTempOrToastNamespace returns false,
and so we mistakenly conclude the lock is not on a temp object.
This coding had bothered me all along because I didn't care for doing a
lot of syscache lookups during transaction commit, but I hadn't realized
that it was outright wrong.
I think we need some better means of recording whether a lock is on a
temp object. We could certainly add a flag to the LOCALLOCK struct,
but it's not clear where a clean place to set it would be. As a rule
we don't yet know when locking a relation whether it's temp or not.
regards, tom lane
