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