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 402bbc8d-728b-4467-8024-31c2bc101ead@uni-muenster.de
Whole thread Raw
In response to Re: Fix bug with accessing to temporary tables of other sessions  (Daniil Davydov <3danissimo@gmail.com>)
Responses Re: Fix bug with accessing to temporary tables of other sessions
List pgsql-hackers

On 09/04/2026 17:29, Daniil Davydov wrote:
> On Thu, Apr 9, 2026 at 9:35 PM Jim Jones <jim.jones@uni-muenster.de> wrote:
> Hm. I see that read_stream_begin_relation immediately calls
> read_stream_begin_impl, where we have a "rel != NULL" check (read_stream.c:787).
> Anyway, I think that we shouldn't rely on the fact that a given Relation will
> always be valid. Please, correct me if I am wrong.
> 
> I see that you don't really like the idea of moving this check. But since a
> vectored variant of ReadBuffer() may be used by anyone, don't we need to take
> it into account?
>> Also, wouldn't it potentially make this check multiple times in a table
>> scan?
> Yep, it will. It is exactly the same logic as for ReadBuffer_common,
> PrefetchBuffer and ReadBufferExtended (i.e. checking this constraint before
> each buffer read). I don't see anything wrong with this approach. More
> precisely, it would be good to avoid multiple checks, but I don't see a way to
> do that.

This check exists because read_stream_begin_smgr_relation() passes NULL,
but I see your point. I guess a check in read_stream_begin_relation()
and in StartReadBuffersImpl() would be the best solution? If you agree,
could you add it in v16?

Thanks!

Best, Jim



pgsql-hackers by date:

Previous
From: Adam Brusselback
Date:
Subject: Re: [Patch] Add WHERE clause support to REFRESH MATERIALIZED VIEW
Next
From: Andrey Borodin
Date:
Subject: Re: Compress prune/freeze records with Delta Frame of Reference algorithm