public inbox for [email protected]
help / color / mirror / Atom feedFrom: Alexander Korotkov <[email protected]>
To: Jim Jones <[email protected]>
Cc: Daniil Davydov <[email protected]>
Cc: Michael Paquier <[email protected]>
Cc: Soumya S Murali <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Stepan Neretin <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Mohamed Ali <[email protected]>
Cc: Nazneen Jafri <[email protected]>
Cc: Shawn McCoy <[email protected]>
Subject: Re: Fix bug with accessing to temporary tables of other sessions
Date: Thu, 7 May 2026 13:43:40 +0300
Message-ID: <CAPpHfdtryHt3yctdiaqPQpDpG+LsBn=VEFVcfV+VwJVQTW1euw@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<CAMtXxw_2VnP5U7U+2ObOCC2voEkAzUqAgH=rPTQBXrb_8K=pyA@mail.gmail.com>
<CAPpHfdtsGSywUExfKMakAuRz8-+61d-4XHkVf=pNQeYTZTVYoA@mail.gmail.com>
<CAMtXxw8J7L0r8aXt9NBFfqqSnaNyU=-_Uq4tW4aO3PHyVeXLAQ@mail.gmail.com>
<CAPpHfdvLCgXgdhSvuPCkek+r=P4E-WiNceWfh7UQztiMzfFcvg@mail.gmail.com>
<[email protected]>
<CAPpHfdsOkkeobCfO9hJvaE2fRcdGmWJoX0umx--DnApmtmefCg@mail.gmail.com>
<CAJDiXgjNySH7Od3nZGjWy30sKv+-12c=kajL7Qfkj3y+CDRwtA@mail.gmail.com>
<CAPpHfds8pwuwF69JFs0SQz58op-U4ddR3KWv0NVEij2mpkzgpw@mail.gmail.com>
<[email protected]>
<CAJDiXgi_SW3DVvXb4+n04NA1YfeeXmT3gUnSG7h4JwBd+RdJGg@mail.gmail.com>
<[email protected]>
<CAJDiXgiyy+GG6a5=nDPQeOQTjdQo53+6N0rAzZ=M3baWGPJNsA@mail.gmail.com>
<CAPpHfdsS49OTo2Af2GeoKJD-1Dy-hOzbje_AWOa_bw5Q9kEi7w@mail.gmail.com>
<[email protected]>
On Thu, May 7, 2026 at 11:43 AM Jim Jones <[email protected]> wrote:
> On 07/05/2026 10:04, Alexander Korotkov wrote:
> > Thus, I don't see the reason why this shouldn't be committed and
> > backpatched to PG17 (first release containing b7b0f3f27241).
>
> Quick question: should we work on a separate patch for PG14-PG16? In
> these versions, the error message is raised depending on the temporary
> table's tuple count, as demonstrated in [1]:
>
> == session 1 ==
>
> psql (14.20 (Debian 14.20-1.pgdg13+1))
> Type "help" for help.
>
> postgres=# CREATE TEMPORARY TABLE t (id int);
> CREATE TABLE
> postgres=# \d pg_temp*.*
> Table "pg_temp_3.t"
> Column | Type | Collation | Nullable | Default
> --------+---------+-----------+----------+---------
> id | integer | | |
>
> == session 2 ==
>
> psql (14.20 (Debian 14.20-1.pgdg13+1))
> Type "help" for help.
>
> postgres=# SELECT * FROM pg_temp_3.t;
> id
> ----
> (0 rows)
>
> == session 1 ==
>
> postgres=# INSERT INTO t VALUES (42);
> INSERT 0 1
>
> == session 2 ==
>
> postgres=# SELECT * FROM pg_temp_3.t;
> ERROR: cannot access temporary tables of other sessions
Thank you for your question. Yes, PostgreSQL 14-16 first does
RelationGetNumberOfBlocks(), then scans the relation through the
buffer manager. If RelationGetNumberOfBlocks() returns 0, then no
buffers accessed and no error thrown. So, it could scan empty tables
because it doesn't requires accessing local buffers of other sessions.
I would investigate this further. If this doesn't have negative side
effects (like execution of other commands that couldn't be performed
correctly), I would avoid backpatching to these versions.
------
Regards,
Alexander Korotkov
Supabase
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Fix bug with accessing to temporary tables of other sessions
In-Reply-To: <CAPpHfdtryHt3yctdiaqPQpDpG+LsBn=VEFVcfV+VwJVQTW1euw@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox