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

From: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "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-03 08:34:50
Message-ID: 47CBB82A.5060704@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> 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?

Good question. It has always seemed a bit strange to me. The assumption
that we always hold the lock on temp table until end of transaction,
while true today, seems weak to me.

> 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.

That certainly seems like the simplest and most robust solution.

There's this corner case where that would behave differently than the
lock manager approach:

BEGIN;
SAVEPOINT sp;
CREATE TEMP TABLE foo(bar int4);
ROLLBACK TO sp;
PREPARE TRANSACTION 'foo';

The flag would have to be per-subxact to avoid that, though I doubt
anyone is relying on that behavior.

In the future, it would be nice to relax the restriction on using temp
rels, though. A flag doesn't lend itself to that easily, but I'm sure
we'll figure out something if we ever get around to implement that.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2008-03-03 10:50:57 Re: Read-ahead and parallelism in redo recovery
Previous Message Pavan Deolasee 2008-03-03 06:46:59 Re: Read-ahead and parallelism in redo recovery