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

From: Soumya S Murali <soumyamurali(dot)work(at)gmail(dot)com>
To: Daniil Davydov <3danissimo(at)gmail(dot)com>
Cc: Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stepan Neretin <slpmcf(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fix bug with accessing to temporary tables of other sessions
Date: 2026-04-16 05:56:09
Message-ID: CAMtXxw8Aua7oLAsFjLuZeb3OLbeU3ijvFAQ4yQRRx17=6oiHGg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi all,

Thank you for the clarification and the updated patch.

On Fri, Apr 10, 2026 at 8:58 PM Daniil Davydov <3danissimo(at)gmail(dot)com> wrote:
>
> Hi,
>
> On Fri, Apr 10, 2026 at 5:29 PM Jim Jones <jim(dot)jones(at)uni-muenster(dot)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=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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jakub Wartak 2026-04-16 06:08:06 Re: Add errdetail() with PID and UID about source of termination signal
Previous Message Jakub Wartak 2026-04-16 05:50:25 Re: Add errdetail() with PID and UID about source of termination signal