Re: Fix bug with accessing to temporary tables of other sessions

Jim Jones <jim.jones@uni-muenster.de>

From: Jim Jones <jim.jones@uni-muenster.de>
To: Soumya S Murali <soumyamurali.work@gmail.com>, Daniil Davydov <3danissimo@gmail.com>
Cc: Stepan Neretin <slpmcf@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2026-03-23T13:31:33Z
Lists: pgsql-hackers

Attachments


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

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Prevent access to other sessions' temp tables

  2. Add tests for cross-session temp table access

  3. Doc: use "an SQL" consistently rather than "a SQL"

  4. Modify the relcache to record the temp status of both local and nonlocal