Re: Fix bug with accessing to temporary tables of other sessions
Soumya S Murali <soumyamurali.work@gmail.com>
From: Soumya S Murali <soumyamurali.work@gmail.com>
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>
Date: 2026-04-21T05:45:06Z
Lists: pgsql-hackers
Hi all, Thank you for reviewing the patch and for the detailed explanation. On Tue, Apr 21, 2026 at 1:37 AM Alexander Korotkov <aekorotkov@gmail.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 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. > 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
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