Re: Fix bug with accessing to temporary tables of other sessions - Mailing list pgsql-hackers

From Jim Jones
Subject Re: Fix bug with accessing to temporary tables of other sessions
Date
Msg-id 1a32fc83-df78-4774-97dc-2bb06dbb16e9@uni-muenster.de
Whole thread Raw
In response to Re: Fix bug with accessing to temporary tables of other sessions  (Soumya S Murali <soumyamurali.work@gmail.com>)
Responses Re: Fix bug with accessing to temporary tables of other sessions
List pgsql-hackers

On 23/03/2026 11:22, Soumya S Murali wrote:
Overall the patch LGTM.


This is a step forward in really isolating contents of temp tables from
other sessions, but the more I think about it, the more I'm concerned
with the current approach -- I spent some time investigating this
problem a bit deeper last week.

My main concern is the usage of gram.y, as a parser is arguably fragile
for this kind of things. For instance, one can always change the
search_path and bypass this restriction:

(table t was created in a different session)

postgres=# SELECT * FROM pg_temp_81.t;
ERROR:  cannot access temporary relations of other sessions
LINE 1: SELECT * FROM pg_temp_81.t;
                      ^
postgres=# SET search_path = pg_temp_81, public;
SET
postgres=# SELECT * FROM t;
 ?column?
----------
(0 rows)

* See: if (relation->relpersistence == RELPERSISTENCE_TEMP) in
namespace.c for more details.

IMO, since it is an access control issue, I guess we better treat it as
such and modify aclchk.c instead.

Something like this the file attached. This breaks an unrelated test,
which is potentially a bug in REPACK ... but I'll describe it in another
thread.

Thoughts?

Best, Jim

Attachment

pgsql-hackers by date:

Previous
From: shawn wang
Date:
Subject: Re: Add logical_decoding_spill_limit to cap spill file disk usage per slot
Next
From: Nazir Bilal Yavuz
Date:
Subject: Re: meson vs. llvm bitcode files