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(at)enterprisedb(dot)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