public inbox for [email protected]  

help / color / mirror / Atom feed
From: Soumya S Murali <[email protected]>
To: Daniil Davydov <[email protected]>
Cc: Jim Jones <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Stepan Neretin <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Fix bug with accessing to temporary tables of other sessions
Date: Thu, 16 Apr 2026 11:26:09 +0530
Message-ID: <CAMtXxw8Aua7oLAsFjLuZeb3OLbeU3ijvFAQ4yQRRx17=6oiHGg@mail.gmail.com> (raw)
In-Reply-To: <CAJDiXgiJ6=79TKnB7qfEGB4UPDZQ7poxDTuvXpZT7e6sBEbfRA@mail.gmail.com>
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>
	<[email protected]>
	<[email protected]>
	<CAJDiXgh9g4TEyF3kWCiBgHX6QbpATZtxTfrQuBCKxUO5=nZBOw@mail.gmail.com>
	<[email protected]>
	<CAJDiXgihovkP6DMAFyJtYF4JSAjvKmiRVbF5R5n3SA=Yag32_w@mail.gmail.com>
	<CAMtXxw8pHLH9+mG3wxsF8f=Y+pHqTNP8X1UmZQPkRL9pZ5aF2w@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<CAJDiXgiAObr4c+PTWSS19vcohrFSDLK3MC5FK3TekMB3U3DjfQ@mail.gmail.com>
	<[email protected]>
	<CAJDiXghBO_TqvHOSui8MOxiFmwLT20+SAnH5nW1rpWHk7Jwffg@mail.gmail.com>
	<[email protected]>
	<CAJDiXgi0JFk0f2KWWQkzLBC5P7erX9WP18qqnbi-rjZ-K-P=3w@mail.gmail.com>
	<[email protected]>
	<CAJDiXgiJ6=79TKnB7qfEGB4UPDZQ7poxDTuvXpZT7e6sBEbfRA@mail.gmail.com>

Hi all,

Thank you for the clarification and the updated patch.

On Fri, Apr 10, 2026 at 8:58 PM Daniil Davydov <[email protected]> wrote:
>
> Hi,
>
> On Fri, Apr 10, 2026 at 5:29 PM Jim Jones <[email protected]> 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=off 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 scans are
> > > # following. Make sure that we cannot access other sessions' temp tables 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 “relation does not exist” 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 “relation
does not exist” 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





reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Fix bug with accessing to temporary tables of other sessions
  In-Reply-To: <CAMtXxw8Aua7oLAsFjLuZeb3OLbeU3ijvFAQ4yQRRx17=6oiHGg@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox