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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables
Дата
Msg-id 24008.1204560223@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  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
Ответы 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>)
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>)
Список pgsql-hackers
"Heikki Linnakangas" <heikki@enterprisedb.com> writes:
> Tom Lane wrote:
>> 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.

Looking back, I think it was driven by the desire to tie the behavior
directly to things that are going to get persisted, such as locks.
From that standpoint your initial patch to attach a temp-check to
relation-drop 2PC entries would be the right kind of design.  However,
given what we now know about the lock situation, I'd feel uncomfortable
with applying that without also fixing LockTagIsTemp, and right now
that's looking like much more complexity and possible performance
penalty than it's worth.

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

Yeah.  As you already noted, there are several other problems that would
have to be dealt with to support that, so we can just leave this as
another one.

Do you want to write up a flag-based patch, or shall I?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Patch application emails
Следующее
От: "Heikki Linnakangas"
Дата:
Сообщение: Re: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables