From: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | LOCK TABLE and DROP TABLE on temp tables of other sessions |
Date: | 2020-02-13 13:09:56 |
Message-ID: | d4a68c6d-d6c4-d52a-56cb-babb8177b5fe@oss.nttdata.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Dolgov | 2020-02-13 13:12:28 | Re: [HACKERS] [PATCH] Generic type subscripting |
Previous Message | Michael Paquier | 2020-02-13 12:04:29 | Re: allow running parts of src/tools/msvc/ under not Windows |