On Thu, Feb 13, 2020 at 6:40 PM Fujii Masao <masao.fu...@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
