LOCK TABLE and DROP TABLE on temp tables of other sessions

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

Responses

Browse pgsql-hackers by date

  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