Re: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables
От | Heikki Linnakangas |
---|---|
Тема | Re: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables |
Дата | |
Msg-id | 47CBB82A.5060704@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: "could not open relation 1663/16384/16584: No such
file or directory" in a specific combination of transactions with
temp tables
Re: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables |
Список | 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
В списке pgsql-hackers по дате отправления: