MIME-Version: 1.0
References: 
 <CAJDiXghdFcZ8=nh4G69te7iRr3Q0uFyXxb3ZdG09_GTNZXwH0g@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>
 <CAJDiXghBO_TqvHOSui8MOxiFmwLT20+SAnH5nW1rpWHk7Jwffg@mail.gmail.com>
 <402bbc8d-728b-4467-8024-31c2bc101ead@uni-muenster.de>
 <CAJDiXgi0JFk0f2KWWQkzLBC5P7erX9WP18qqnbi-rjZ-K-P=3w@mail.gmail.com>
 <086c2108-0d46-4711-82df-19eb06a55326@uni-muenster.de>
 <CAJDiXgiJ6=79TKnB7qfEGB4UPDZQ7poxDTuvXpZT7e6sBEbfRA@mail.gmail.com>
In-Reply-To: 
 <CAJDiXgiJ6=79TKnB7qfEGB4UPDZQ7poxDTuvXpZT7e6sBEbfRA@mail.gmail.com>
From: Soumya S Murali <soumyamurali.work@gmail.com>
Date: Thu, 16 Apr 2026 11:26:09 +0530
Message-ID: 
 <CAMtXxw8Aua7oLAsFjLuZeb3OLbeU3ijvFAQ4yQRRx17=6oiHGg@mail.gmail.com>
Subject: Re: Fix bug with accessing to temporary tables of other sessions
To: Daniil Davydov <3danissimo@gmail.com>
Cc: Jim Jones <jim.jones@uni-muenster.de>, 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/CAMtXxw8Aua7oLAsFjLuZeb3OLbeU3ijvFAQ4yQRRx17%3D6oiHGg%40mail.gmail.com>
Precedence: bulk

Hi all,

Thank you for the clarification and the updated patch.

On Fri, Apr 10, 2026 at 8:58=E2=80=AFPM Daniil Davydov <3danissimo@gmail.co=
m> wrote:
>
> Hi,
>
> On Fri, Apr 10, 2026 at 5:29=E2=80=AFPM Jim Jones <jim.jones@uni-muenster=
.de> wrote:
> >
> > > BTW, what do you think about making this comment less "concrete"? :
> > > # SELECT via index scan from other session.
> > > # Sequential scans are blocked at read_stream_begin_relation(); index=
 scans
> > > # bypass that path entirely and reach ReadBufferExtended() in bufmgr.=
c
> > > # (nbtree's _bt_getbuf calls ReadBuffer directly for individual page =
fetches).
> > > # enable_seqscan=3Doff forces the planner to use the index.
> > >
> > > I mean that if the described logic changes, this comment will become =
confusing.
> > > We can describe the test in general words. For example :
> > > # Index scans can use a different code path from the one sequential s=
cans are
> > > # following. Make sure that we cannot access other sessions' temp tab=
les during
> > > # index scan either.
> >
> > +1
> >
> > Yeah, it's indeed too verbose. I guess these comments were originally
> > just for me so I wouldn't get too confused along the way :)
>
> OK :)
>
> >
> > I don't have anything else to add at this point. Unless there are any
> > objections, I'll mark the CF entry as 'Ready for Committer.'
> >
>
> Great, thank you!
>
> Please, see an updated set of patches (only perl test has been changed) :
> 1) Rephrase the discussed comment.
> 2) Use safe_psql whenever possible.
> 3) Run pgperltidy.


You were right. In my earlier testing I was not using the explicit
temporary schema, which resulted in =E2=80=9Crelation does not exist=E2=80=
=9D due to
namespace resolution. I have now re-tested using the correct temporary
schema of the owning session, and I can confirm that the patch behaves
as expected. Cross-session access consistently throws: ERROR: cannot
access temporary relations of other sessions
Verified across multiple execution paths including SELECT, COUNT(*),
JOINs, subqueries, and DML operations. Index scan paths (with seqscan
disabled) are also correctly blocked with ERROR: cannot access
temporary relations of other sessions. Same-session access continues
to work as expected. Metadata access (pg_relation_size) behaves
correctly and does not expose incorrect data. Cases where =E2=80=9Crelation
does not exist=E2=80=9D appears are due to referencing an
incorrect temp schema, which is expected. Overall, the patch correctly
prevents access across all tested paths.
Thank you for pointing this out.

Regards,
Soumya