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

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 AM 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 PM Jim Jones <jim.jones@uni-muenster.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.

------
Regards,
Alexander Korotkov
Supabase