Re: LOCK TABLE and DROP TABLE on temp tables of other sessions

Поиск
Список
Период
Сортировка
От Ashutosh Bapat
Тема Re: LOCK TABLE and DROP TABLE on temp tables of other sessions
Дата
Msg-id CAExHW5vJrVLtW+Ud5ET4ZdKhod0JYkcOneJZ37oqGbsMa6HoQg@mail.gmail.com
обсуждение исходный текст
Ответ на LOCK TABLE and DROP TABLE on temp tables of other sessions  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Ответы Re: LOCK TABLE and DROP TABLE on temp tables of other sessions  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers


On Thu, Feb 13, 2020 at 6:40 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
Hi,

TRUNCATE command on the temporary tables of other sessions fails
with the following error. This behavior looks expected to me.

     ERROR:  cannot truncate temporary tables of other sessions

However I found that LOCK TABLE and DROP TABLE commands on
the temporary tables of other sessions are successfully processed,
if users (like superusers) have enough access privileges on them.
Is this a bug? ISTM that the similar check that TRUNCATE command
does needs to be added even in LOCK TABLE and DROP TABLE cases.

That looks odd. Other sessions are able to see temporary tables of a given session because they are stored in the same catalog which is accessible to all the sessions. But ideally, a temporary table should be visible only to the session which created it (GTT is an exception). So LOCK and DROP table should not succeed.

Thinking from a different perspective, DROP TABLE being able to drop a temporary table seems a good tool in case a temporary table is left behind by a finished session. But that doesn't seem like a good reason to have it and I don't see much use of LOCK TABLE there.
 

BTW, even SELECT has the same issue. Basically SELECT on
the temporary tables of other sessions fails with the following
error.

     ERROR:  cannot access temporary tables of other sessions

However if the temporary table is empty, SELECT doesn't reach
the above check, is successfully processed and the relation lock
is taken. This lock can prevent the backend process that created
the temporary table from exiting even when the client that
the backend is connecting to quits. Seems it's problematic.

Regards,

--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters




--
--
Best Wishes,
Ashutosh Bapat

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Fix compiler warnings on 64-bit Windows
Следующее
От: Tom Lane
Дата:
Сообщение: Re: allow running parts of src/tools/msvc/ under not Windows