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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "John Smith" <sodgodofall(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables
Date: 2008-03-02 00:51:01
Message-ID: 8882.1204419061@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> 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.

Actually ... why are we using the lock manager to drive this at all?
Temp-ness of relations is not really something that it has any interest
in. What if we get rid of LockTagIsTemp altogether, and instead protect
2PC transactions by having a global flag "transactionUsedTempTable"?
We could clear that at transaction start, and conditionally set it in
relation_open, for very little cost.

I think the idea behind the lock-manager approach was to avoid expending
any cycles at all on this consideration if you weren't using 2PC. But
if we have to take special action to mark locks as temp when they are
taken, we certainly aren't going to beat a simple flag for performance.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message craigp 2008-03-02 10:36:33 newbie: renaming sequences task
Previous Message Gurjeet Singh 2008-03-02 00:02:09 Fwd: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables