MIME-Version: 1.0
References: 
 <CAJDiXghdFcZ8=nh4G69te7iRr3Q0uFyXxb3ZdG09_GTNZXwH0g@mail.gmail.com>
 <2f3fa419-9000-4e2a-b070-6e35d5de0e4c@uni-muenster.de>
 <CAJDiXgghbz2TL1b5HbvB7pQzM6S4QDxcuLP-tyOzj1tZunvXJA@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>
In-Reply-To: <67637cf8-8cbf-4f86-8775-52aa0329972d@uni-muenster.de>
From: Soumya S Murali <soumyamurali.work@gmail.com>
Date: Mon, 13 Apr 2026 18:06:03 +0530
Message-ID: 
 <CAMtXxw9nzcUAERM6ScpYrVXAm4gut_+chrEp4H-aznzvv5qckg@mail.gmail.com>
Subject: Re: Fix bug with accessing to temporary tables of other sessions
To: Jim Jones <jim.jones@uni-muenster.de>
Cc: Daniil Davydov <3danissimo@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/CAMtXxw9nzcUAERM6ScpYrVXAm4gut_%2BchrEp4H-aznzvv5qckg%40mail.gmail.com>
Precedence: bulk

Hi all,

On Wed, Apr 8, 2026 at 4:11=E2=80=AFPM Jim Jones <jim.jones@uni-muenster.de=
> wrote:
>
> Hi
>
> On 08/04/2026 11:17, Soumya S Murali wrote:
> > I worked on the issue of accessing temporary tables belonging to other
> > sessions and tried implementing the fix at the buffer manager level,
> > as suggested. I added checks in ReadBuffer_common() and
> > PrefetchBuffer() to reject access when a relation is temporary
> > (relpersistence =3D TEMP) but does not use local buffers
> > (!RelationUsesLocalBuffers) so that it ensures only heap page access
> > is blocked, while catalog lookups and other metadata operations
> > continue to work as before. While testing, I observed that in many
> > cases the query does not reach the buffer manager because name
> > resolution fails earlier with =E2=80=9Crelation does not exist=E2=80=9D=
. However, the
> > added checks ensure that even if execution reaches the buffer layer,
> > access to other sessions=E2=80=99 temporary tables is safely rejected. =
The
> > change is minimal, and did not modify parser/ACL behavior and all
> > regression tests got passed successfully too.
> > Kindly review the attached patch herewith. Please let me know if this
> > approach aligns with expectations or if further adjustments are
> > needed.
>
> A few comments:
>
> =3D=3D PrefetchBuffer =3D=3D
>
> The condition nested inside the if (RelationUsesLocalBuffers(reln))
> tests the opposite of the main if !RelationUsesLocalBuffers(reln):
>
> if (RelationUsesLocalBuffers(reln))
> {
>   /* ACCESS DENIED CHECK */
>   if (reln !=3D NULL &&
>   reln->rd_rel !=3D NULL &&
>   reln->rd_rel->relpersistence =3D=3D RELPERSISTENCE_TEMP &&
>   !RelationUsesLocalBuffers(reln))
>   {
>   ereport(ERROR,
>         (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
>         errmsg("cannot access temporary tables of other sessions")));
>   }
> ...
> }
>
> So it'll be always false, making the ereport unreachable.
>
> =3D=3D ReadBufferExtended =3D=3D
>
> These conditions cancel each other out:
>
> if (reln->rd_rel->relpersistence =3D=3D RELPERSISTENCE_TEMP &&
>     !RelationUsesLocalBuffers(reln))
>
> RelationUsesLocalBuffers(reln) expands to
> ((relation)->rd_rel->relpersistence =3D=3D RELPERSISTENCE_TEMP), making t=
he
> error message unreachable. Perhaps you meant RELATION_IS_OTHER_TEMP?
>
> =3D=3D ReadBuffer_common =3D=3D
>
> Same as in ReadBufferExtended and PrefetchBuffer.
>
> =3D=3D tests =3D=3D
>
> You excluded the tests from the patch.
>
> =3D=3D patch version =3D=3D
>
> You forgot to add the patch version.


Thank you for the detailed review and for pointing out these issues. I
understood that the condition I used with RelationUsesLocalBuffers()
was incorrect and made the checks unreachable. Also the
RELATION_IS_OTHER_TEMP() was not the appropriate macro to use here.
Regarding PrefetchBuffer, placing the check inside the
RelationUsesLocalBuffers() branch was also logically inconsistent.
Apologies for missing the tests and patch versioning in my submission.
I will ensure these are included properly in future iterations. Based
on the subsequent discussion and the analysis of the regression
introduced by routing through read_stream_next_buffer(), I agree that
the fix is better in the read stream / buffer read entry points rather
than only in bufmgr.
Thank you for your guidance. It really helped clarify both the root
cause and the correct placement of the fix.

Regards,
Soumya