On Thu, May 7, 2026 at 11:43 AM Jim Jones <jim.jones@uni-muenster.de> 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
