Re: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables

"Heikki Linnakangas" <heikki@enterprisedb.com> writes:
> I think I see what's happening here. We have restricted two-phase commit 
> so that you're not supposed to be able to PREPARE TRANSACTION if the 
> transaction has touched any temporary tables. That's because the 2nd 
> phase commit can be performed from another backend, and another backend 
> can't mess with another backend's temporary tables.

> However in this case, where you CREATE and DROP the temporary table in 
> the same transaction, we don't detect that, and let the PREPARE 
> TRANSACTION to finish. The detection relies on the lock manager, but 
> we're not holding any locks on the dropped relation.

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'm dissatisfied with the proposed patch because I'm afraid it's
patching a symptom rather than whatever the real problem is.
        regards, tom lane