MIME-Version: 1.0
References: 
 <CAJDiXghdFcZ8=nh4G69te7iRr3Q0uFyXxb3ZdG09_GTNZXwH0g@mail.gmail.com>
 <751a6cb8-cac8-46c4-8c64-9e23f663e926@uni-muenster.de>
 <CAJDiXgiMg_f0A1aESQrwFzeAkUieXBy8vFq_zisvTKQcGQJcCg@mail.gmail.com>
 <CAJDiXgj5rFYxuLYSpQxidQ+1cZ=6rJx29MvV+RAjKX7B=EGUvw@mail.gmail.com>
 <CAJDiXggOEN06RwBBCJ-egzkmTbm81=LJ5eCNmvzr=Bpwnp5VzA@mail.gmail.com>
 <CAJDiXgi7tWm_y0i7kD8fMxGe=86_W-hMxyQS+g7-7cdTzd-KRQ@mail.gmail.com>
 <CAMtXxw_ta_9i=uPJMvGueOBc04crmraJXcyJhN0K=Wu9aa2rog@mail.gmail.com>
 <1a32fc83-df78-4774-97dc-2bb06dbb16e9@uni-muenster.de>
 <3529398.1774273446@sss.pgh.pa.us>
 <CAJDiXgh9g4TEyF3kWCiBgHX6QbpATZtxTfrQuBCKxUO5=nZBOw@mail.gmail.com>
 <4075754.1774378690@sss.pgh.pa.us>
 <CAJDiXgihovkP6DMAFyJtYF4JSAjvKmiRVbF5R5n3SA=Yag32_w@mail.gmail.com>
 <CAMtXxw8pHLH9+mG3wxsF8f=Y+pHqTNP8X1UmZQPkRL9pZ5aF2w@mail.gmail.com>
 <67637cf8-8cbf-4f86-8775-52aa0329972d@uni-muenster.de>
 <b13dc5ba-6c11-429c-b6fe-673c1c767bcf@uni-muenster.de>
 <CAJDiXgiAObr4c+PTWSS19vcohrFSDLK3MC5FK3TekMB3U3DjfQ@mail.gmail.com>
 <e58a9580-7bbf-4d70-ad99-833fab77cf88@uni-muenster.de>
In-Reply-To: <e58a9580-7bbf-4d70-ad99-833fab77cf88@uni-muenster.de>
From: Daniil Davydov <3danissimo@gmail.com>
Date: Thu, 9 Apr 2026 22:29:52 +0700
Message-ID: 
 <CAJDiXghBO_TqvHOSui8MOxiFmwLT20+SAnH5nW1rpWHk7Jwffg@mail.gmail.com>
Subject: Re: Fix bug with accessing to temporary tables of other sessions
To: Jim Jones <jim.jones@uni-muenster.de>
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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAJDiXghBO_TqvHOSui8MOxiFmwLT20%2BSAnH5nW1rpWHk7Jwffg%40mail.gmail.com>
Precedence: bulk

Hi,

On Thu, Apr 9, 2026 at 9:35=E2=80=AFPM Jim Jones <jim.jones@uni-muenster.de=
> wrote:
>
> On 09/04/2026 13:46, Daniil Davydov wrote:
> > 1) Right now, read stream seems like an appropriate place for this rest=
riction.
> > But actually the StartReadBuffers is not "binded" to the read stream lo=
gic. 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 aga=
in.
> > I think that it will be more reliable to add the restriction directly t=
o 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 t=
o leave restriction in the "read_stream_begin_relation"
> > function, I would suggest adding a "rel !=3D NULL" check here (read_str=
eam.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 !=3D NULL" checks may use the "RelationIsValid" macro, whic=
h 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 !=3D NULL is not needed.

Hm. I see that read_stream_begin_relation immediately calls
read_stream_begin_impl, where we have a "rel !=3D NULL" check (read_stream.=
c:787).
Anyway, I think that we shouldn't rely on the fact that a given Relation wi=
ll
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 ta=
ke
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.

--
Best regards,
Daniil Davydov