public inbox for [email protected]
help / color / mirror / Atom feedFrom: 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: Mon, 13 Apr 2026 18:10:09 +0530
Message-ID: <CAMtXxw_hBNuAWQUdSRMpoeRVRYr+5+S7p0bSzuqtHxfpzJPd3w@mail.gmail.com> (raw)
In-Reply-To: <CAJDiXgi0JFk0f2KWWQkzLBC5P7erX9WP18qqnbi-rjZ-K-P=3w@mail.gmail.com>
References: <CAJDiXghdFcZ8=nh4G69te7iRr3Q0uFyXxb3ZdG09_GTNZXwH0g@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>
<[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>
Hi all,
On Fri, Apr 10, 2026 at 12:40 PM Daniil Davydov <[email protected]> wrote:
>
> Hi,
>
> On Fri, Apr 10, 2026 at 12:46 AM Jim Jones <[email protected]> wrote:
> >
> > 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?
>
> Having both checks might look a bit redundant since the read stream will
> eventually call the StartReadBuffersImpl function. On the other hand, there are
> many places which are checking this restriction even if subsequent functions
> (from bufmgr) also have this check.
>
> So, I'll keep both checks and a bit reduce the comments in the bufmgr.c .
>
> 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.
>
>
> Thank you for the comments! Please, see an updated set of patches.
>
I tested the v16 patch on a clean tree and verified the behavior
across multiple execution paths. Same-session access to temporary
tables works as expected. Cross-session access is consistently
blocked; all attempts result in an error - "relation does not exist"
and no incorrect or empty result sets were observed. In many cases,
access is blocked earlier with “relation does not exist”, while the
patch ensures that deeper execution paths are also protected. Verified
both sequential and index scan paths (after disabling seqscan), and
access is correctly rejected in all the cases. Tested various query
forms including SELECT, COUNT(*), JOINs, subqueries, DML operations,
and EXPLAIN ANALYZE none allowed access to other sessions’ temporary
tables. pg_relation_size() returns metadata as expected and does not
expose incorrect data.
Please let me know if there are additional scenarios I should
validate. Looking forward to more feedback.
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: <CAMtXxw_hBNuAWQUdSRMpoeRVRYr+5+S7p0bSzuqtHxfpzJPd3w@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