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

From: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Daniil Davydov <3danissimo(at)gmail(dot)com>, Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>, Soumya S Murali <soumyamurali(dot)work(at)gmail(dot)com>, 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>, Mohamed Ali <moali(dot)pg(at)gmail(dot)com>, Nazneen Jafri <jafrinazneen(at)gmail(dot)com>, Shawn McCoy <shawn(dot)the(dot)mccoy(at)gmail(dot)com>
Subject: Re: Fix bug with accessing to temporary tables of other sessions
Date: 2026-05-14 06:12:58
Message-ID: CAPpHfdsJM3KRLkkSqijmdJnw+y-ofwCyaAJCSpjxCbThT3oTew@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi, Michael!

On Fri, May 8, 2026 at 9:19 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Thu, May 07, 2026 at 11:04:16AM +0300, Alexander Korotkov wrote:
> > Let me do a quick summary:
> > * Our buffer manager is not capable for reading temp tables of other sessions.
> > * This was covered by explicit checks, but broken since b7b0f3f27241
> > introduced alternative code path for reading tables.
> > * This doesn't apply to DROP TABLE. DROP TABLE is a conscious
> > exclusion and the only operation we can do correctly for other
> > session' temp tables. There is an explicit exclusion in the code to
> > skip the attempt to cleanup buffers of other session' temp tables.
> > * This patchset consists of tests (0001) for various operations with
> > other session's temp tables including buggy behavior, and the fix
> > (0002) including changes for tests.
> >
> > Thus, I don't see the reason why this shouldn't be committed and
> > backpatched to PG17 (first release containing b7b0f3f27241).
> > Opinions? Michael?
>
> Hmm. I don't have any counter-arguments against a backpatch based on
> your argument related to b7b0f3f27241. Thanks for reorganizing the
> patch set so as the tests happen first, and the changes in the code
> become second.
>
> If you wish me to look at this patch set in details, I may be able to
> do so around the beginning of next week. I'm not sure that there is a
> strong urgency in tackling this issue for this minor release, this
> could wait a bit more..

Any news from your side?

------
Regards,
Alexander Korotkov
Supabase

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2026-05-14 06:25:51 Re: [SQL/PGQ] Early pruning for GRAPH_TABLE path generation
Previous Message Michael Paquier 2026-05-14 06:02:18 Re: Fix jsonpath .split_part() to honor silent mode