We broke the defense against accessing other sessions' temp tables

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: We broke the defense against accessing other sessions' temp tables
Date: 2025-09-21 17:32:59
Message-ID: 2736425.1758475979@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

In session 1:

regression=# create temp table tt(f1 int);
CREATE TABLE
regression=# insert into tt values(44);
INSERT 0 1
regression=# \d tt
Table "pg_temp_77.tt"
Column | Type | Collation | Nullable | Default
--------+---------+-----------+----------+---------
f1 | integer | | |

In session 2:

regression=# select * from pg_temp_77.tt; -- use the schema shown in session 1
f1
----
(0 rows)

Branches before 17 show the expected failure

ERROR: cannot access temporary tables of other sessions

but that's gone missing :-(. Apparently, we refactored things enough
that ReadBufferExtended is not used for a simple seqscan, and since
that's where the check for an other-session temp table is, we get
no error and instead bogus results. I did not bother to bisect to
find a culprit commit, but given that the failure manifests in 17,
I'm betting the stream I/O stuff is at fault.

I experimented with moving the check into PinBufferForBlock, and
that seems to work correctly, but I wonder if someone who's messed
with this code more recently than I would prefer a different
solution.

regards, tom lane

Attachment Content-Type Size
v1-move-check-for-other-temp-table.patch text/x-diff 1.7 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-09-21 17:34:15 Re: Add notification on BEGIN ATOMIC SQL functions using temp relations
Previous Message Pavel Stehule 2025-09-21 17:14:36 Re: Add notification on BEGIN ATOMIC SQL functions using temp relations