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: Daniil Davydov <3danissimo@gmail.com>
Cc: Soumya S Murali <soumyamurali.work@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Stepan Neretin <slpmcf@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2026-04-09T14:35:29Z
Lists: pgsql-hackers
Hi Daniil

On 09/04/2026 13:46, Daniil Davydov wrote:
> 1) Right now, read stream seems like an appropriate place for this restriction.
> But actually the StartReadBuffers is not "binded" to the read stream logic. I
> mean that if someone calls it bypassing the "read_stream_begin_relation"
> function (it is OK to do so), then our restriction will be violated again.
> I think that it will be more reliable to add the restriction directly to the
> StartReadBuffers. Also, we can add an assertion ("relation is not other temp
> table") to the PinBufferForBlock. What do you think?> 2) If we decide to leave restriction in the "read_stream_begin_relation"
> function, I would suggest adding a "rel != NULL" check here (read_stream.c):
> +    if (RELATION_IS_OTHER_TEMP(rel))
> +        ereport(ERROR,
> +                (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
> +                 errmsg("cannot access temporary relations of other
> sessions")));
> 3) The "rel != NULL" checks may use the "RelationIsValid" macro, which seems
> more pretty to me.


Mm, not so sure...
AFAICT moving the check to StartReadBuffersImpl would require an extra
NULL guard that isn't needed in read_stream_begin_relation, as the
callers already pass valid Relations. So, rel != NULL is not needed.

Also, wouldn't it potentially make this check multiple times in a table
scan?

Am I missing something?

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