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

Hi,

On Wed, Apr 8, 2026 at 9:04 PM Jim Jones <jim.jones@uni-muenster.de> wrote:
>
> I did some digging:
>
> It seems that b7b0f3f2724 is what actually broke it. By switching from
> ReadBufferExtended() to read_stream_next_buffer(), it silently routed
> all SELECT/UPDATE/DELETE/COPY away from the check that was sitting in
> ReadBufferExtended().
>

Yeah, I agree with your conclusions.

> It simply builds upon 210622c60e1 (introduces StartReadBuffers ->
> PinBufferForBlock) and b5a9b18cd0b (builds read_stream_begin_relation on
> top of it).
>
> So I thought we can explore the option of adding this check directly in
> read_stream_begin_relation():
>
>
> if (RELATION_IS_OTHER_TEMP(rel))
>   ereport(ERROR,
>          (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
>       errmsg("cannot access temporary relations of other sessions")));
>
>
> Thoughts?
>

Thank you very much for the patch! A few comments:

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.

> Daniil, feel free to revert it to your last patch if you disagree with
> this approach.

This approach looks good to me after Tom's explanations.

--
Best regards,
Daniil Davydov