MIME-Version: 1.0
References: 
 <CAJDiXghdFcZ8=nh4G69te7iRr3Q0uFyXxb3ZdG09_GTNZXwH0g@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>
 <CAMtXxw_hBNuAWQUdSRMpoeRVRYr+5+S7p0bSzuqtHxfpzJPd3w@mail.gmail.com>
 <b6614954-6c71-451a-a1d7-345d255b4afb@uni-muenster.de>
 <CAMtXxw_2VnP5U7U+2ObOCC2voEkAzUqAgH=rPTQBXrb_8K=pyA@mail.gmail.com>
 <CAPpHfdtsGSywUExfKMakAuRz8-+61d-4XHkVf=pNQeYTZTVYoA@mail.gmail.com>
In-Reply-To: 
 <CAPpHfdtsGSywUExfKMakAuRz8-+61d-4XHkVf=pNQeYTZTVYoA@mail.gmail.com>
From: Soumya S Murali <soumyamurali.work@gmail.com>
Date: Tue, 21 Apr 2026 11:15:06 +0530
Message-ID: 
 <CAMtXxw8J7L0r8aXt9NBFfqqSnaNyU=-_Uq4tW4aO3PHyVeXLAQ@mail.gmail.com>
Subject: Re: Fix bug with accessing to temporary tables of other sessions
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Jim Jones <jim.jones@uni-muenster.de>,
 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/CAMtXxw8J7L0r8aXt9NBFfqqSnaNyU%3D-_Uq4tW4aO3PHyVeXLAQ%40mail.gmail.com>
Precedence: bulk

Hi all,

Thank you for reviewing the patch and for the detailed explanation.

On Tue, Apr 21, 2026 at 1:37=E2=80=AFAM Alexander Korotkov <aekorotkov@gmai=
l.com> wrote:
>
> Hi!
>
> I've checked the thread.  Thanks to all the participants for their
> work.  I think there is a general agreement on the design.
>
> On Thu, Apr 16, 2026 at 9:41=E2=80=AFAM Soumya S Murali
> <soumyamurali.work@gmail.com> wrote:
> > Thank you for the guidance and the updated patch.
> >
> > On Mon, Apr 13, 2026 at 7:26=E2=80=AFPM Jim Jones <jim.jones@uni-muenst=
er.de> wrote:
> > >
> > > Hi
> > >
> > > On 13/04/2026 14:40, Soumya S Murali wrote:
> > > > Please let me know if there are additional scenarios I should
> > > > validate. Looking forward to more feedback.
> > >
> > > Thanks for testing it. You can take a look at
> > > 012_temp_obj_multisession.pl and check if we missed any path.
> > >
> > > Due to changes introduced in b2a17ba7a5d the patch was no longer
> > > applying. See rebased v18 attached.
> > >
> >
> >
> > I tested the rebased v18 patch on a clean tree and verified that it
> > applies cleanly and behaves consistently with previous results.
> > Cross-session access is correctly blocked with: ERROR: cannot access
> > temporary relations of other sessions
> > Index scan paths are also properly restricted, and same-session access
> > continues to work as expected.
> > The updated test changes look good. Everything works as expected, +1
> > from my side.
>
> I see the patch changes the error wording.  Previously the error was
> "cannot access temporary tables of other sessions", but we change it
> to "cannot access temporary relation of other sessions".  I see the
> intention here: we trigger an error while accessing some relation (not
> necessarily a table) then we should reflect this directly to the error
> message.  However, old message is already here for quite a while and
> translated into many languages.  Also, is old message incorrect?  We
> trigger an error on buffer access.  That is, we trigger an error only
> for relation with a storage: table, index, sequence or matview.
> Matview can't be temporary.  Also, if you access an index with a
> query, that means you're querying its table.  But sequence can be
> temporary and it can be not directly associated with a table.  So,
> yes, new error message is more correct.  But I would prefer to make it
> a separate patch, and replace all the occurrences including contrib.
>


This makes sense. While the new wording is indeed more precise, I
agree that changing an existing error message, especially one that has
been present for a long time and is already translated, should be
handled
separately from the bug fix. Keeping the current message for this
patch and addressing wording improvements in a dedicated follow-up
patch sounds like the right approach.
Thanks for pointing this out.

Regards,
Soumya