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 →
-
Prevent access to other sessions' temp tables
- 4dfae59a1d31 17 (unreleased) landed
- 1b0dd08157bf 18 (unreleased) landed
- ce146621f786 19 (unreleased) landed
-
Add tests for cross-session temp table access
- 40927d458fe1 17 (unreleased) landed
- 1cd37a7a8dc6 18 (unreleased) landed
- 1fee0e857e33 19 (unreleased) landed
-
Doc: use "an SQL" consistently rather than "a SQL"
- b51f86e49a7f 18.0 cited
-
Modify the relcache to record the temp status of both local and nonlocal
- 948d6ec90fd3 8.4.0 cited