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: Daniil Davydov <3danissimo@gmail.com>
Cc: Jim Jones <jim.jones@uni-muenster.de>, Tom Lane <tgl@sss.pgh.pa.us>, Stepan Neretin <slpmcf@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2026-04-16T05:56:09Z
Lists: pgsql-hackers
Hi all, Thank you for the clarification and the updated patch. On Fri, Apr 10, 2026 at 8:58 PM Daniil Davydov <3danissimo@gmail.com> wrote: > > Hi, > > On Fri, Apr 10, 2026 at 5:29 PM Jim Jones <jim.jones@uni-muenster.de> wrote: > > > > > BTW, what do you think about making this comment less "concrete"? : > > > # SELECT via index scan from other session. > > > # Sequential scans are blocked at read_stream_begin_relation(); index scans > > > # bypass that path entirely and reach ReadBufferExtended() in bufmgr.c > > > # (nbtree's _bt_getbuf calls ReadBuffer directly for individual page fetches). > > > # enable_seqscan=off forces the planner to use the index. > > > > > > I mean that if the described logic changes, this comment will become confusing. > > > We can describe the test in general words. For example : > > > # Index scans can use a different code path from the one sequential scans are > > > # following. Make sure that we cannot access other sessions' temp tables during > > > # index scan either. > > > > +1 > > > > Yeah, it's indeed too verbose. I guess these comments were originally > > just for me so I wouldn't get too confused along the way :) > > OK :) > > > > > I don't have anything else to add at this point. Unless there are any > > objections, I'll mark the CF entry as 'Ready for Committer.' > > > > Great, thank you! > > Please, see an updated set of patches (only perl test has been changed) : > 1) Rephrase the discussed comment. > 2) Use safe_psql whenever possible. > 3) Run pgperltidy. You were right. In my earlier testing I was not using the explicit temporary schema, which resulted in “relation does not exist” due to namespace resolution. I have now re-tested using the correct temporary schema of the owning session, and I can confirm that the patch behaves as expected. Cross-session access consistently throws: ERROR: cannot access temporary relations of other sessions Verified across multiple execution paths including SELECT, COUNT(*), JOINs, subqueries, and DML operations. Index scan paths (with seqscan disabled) are also correctly blocked with ERROR: cannot access temporary relations of other sessions. Same-session access continues to work as expected. Metadata access (pg_relation_size) behaves correctly and does not expose incorrect data. Cases where “relation does not exist” appears are due to referencing an incorrect temp schema, which is expected. Overall, the patch correctly prevents access across all tested paths. Thank you 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