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

Alexander Korotkov <aekorotkov@gmail.com>

From: Alexander Korotkov <aekorotkov@gmail.com>
To: Daniil Davydov <3danissimo@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Jim Jones <jim.jones@uni-muenster.de>, Soumya S Murali <soumyamurali.work@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Stepan Neretin <slpmcf@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Mohamed Ali <moali.pg@gmail.com>, Nazneen Jafri <jafrinazneen@gmail.com>, Shawn McCoy <shawn.the.mccoy@gmail.com>
Date: 2026-06-30T11:46:45Z
Lists: pgsql-hackers
Hi, Daniil!

On Thu, May 14, 2026 at 7:49 PM Daniil Davydov <3danissimo@gmail.com> wrote:
> On Thu, May 14, 2026 at 8:39 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:
> >
> > On Thu, May 14, 2026 at 9:58 AM Michael Paquier <michael@paquier.xyz> wrote:
> > > On Thu, May 14, 2026 at 09:12:58AM +0300, Alexander Korotkov wrote:
> > > > On Fri, May 8, 2026 at 9:19 AM Michael Paquier <michael@paquier.xyz> wrote:
> > > >> 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?
> > >
> > > (Forgot -hackers and other folks in CC, sorry about that.)
> > >
> > > Unfortunately I have not been able to get back to it this week, and
> > > next week is moot.  Perhaps it is better to not wait for me here, so
> > > feel free to go ahead as you feel.
> >
> > Thank you for noticing.  I've pushed this today.  I have to slightly
> > revise the tests to run on 18 and 17 (different log messages, and
> > default value of log_lock_waits).
> >
>
> Thank you very much for your help!)

You're welcome )

> BTW, we still have another problem with temp tables. Tom wrote [1] about it
> within this thread:
>
> > Reality is that we cannot know whether an
> > unqualified-name RangeVar references a temp table until we do a
> > catalog lookup, so IMO we should not have a relpersistence field there
> > at all. At best it means something quite different from what it means
> > elsewhere, and that's a recipe for confusion. But changing that would
> > not be a bug fix (AFAIK) but refactoring to reduce the probability of
> > future bugs.
>
> I'll try to implement that next month. But if someone gets ahead of me, please
> attach me in CC of the new thread.
>
> [1] https://www.postgresql.org/message-id/4075754.1774378690%40sss.pgh.pa.us

Just a friendly ping on how is it going.

------
Regards,
Alexander Korotkov
Supabase



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Prevent access to other sessions' temp tables

  2. Add tests for cross-session temp table access

  3. Doc: use "an SQL" consistently rather than "a SQL"

  4. Modify the relcache to record the temp status of both local and nonlocal