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

On Thu, Feb 13, 2020 at 6:40 PM Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)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