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

From Tom Lane
Subject Re: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables
Date
Msg-id 4435.1204405872@sss.pgh.pa.us
Whole thread Raw
In response to 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>)
Responses Re: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables
List pgsql-hackers
"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


pgsql-hackers by date:

Previous
From: "Hiroshi Saito"
Date:
Subject: Re: OSSP can be used in the windows environment now!
Next
From: Tom Lane
Date:
Subject: Re: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables