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
