Re: Fix bug with accessing to temporary tables of other sessions - Mailing list pgsql-hackers

From Jim Jones
Subject Re: Fix bug with accessing to temporary tables of other sessions
Date
Msg-id 800c75af-9bd0-48ac-b4bf-54cadf2bc723@uni-muenster.de
Whole thread
In response to Re: Fix bug with accessing to temporary tables of other sessions  (Jim Jones <jim.jones@uni-muenster.de>)
List pgsql-hackers

On 25/04/2026 01:01, Jim Jones wrote:
> Until PG16 an error message was raised:
> 
> psql (16.13 (Debian 16.13-1.pgdg13+1))
> Type "help" for help.
> 
> postgres=# \d pg_temp*.*
>                     Table "pg_temp_3.t"
>      Column      |  Type   | Collation | Nullable | Default
> -----------------+---------+-----------+----------+---------
>  generate_series | integer |           |          |
> 
> postgres=# SELECT * FROM pg_temp_3.t;
> ERROR:  cannot access temporary tables of other sessions


The PG16 test above was against a non-empty TEMPORARY TABLE. If the
table is empty, the same behaviour from PG17 and PG18 can be observed:

psql (16.13 (Debian 16.13-1.pgdg13+1))
Type "help" for help.

postgres=# \d pg_temp*.*
                Table "pg_temp_4.t"
 Column |  Type   | Collation | Nullable | Default
--------+---------+-----------+----------+---------
 id     | integer |           |          |

postgres=# SELECT * FROM pg_temp_4.t;
 id
----
(0 rows)

The same applies for PG14 and PG15

psql (14.22 (Debian 14.22-1.pgdg13+1))
Type "help" for help.

postgres=# \d pg_temp*.*
                Table "pg_temp_3.t"
 Column |  Type   | Collation | Nullable | Default
--------+---------+-----------+----------+---------
 id     | integer |           |          |

postgres=# SELECT * FROM pg_temp_3.t;
 id
----
(0 rows)

psql (15.17 (Debian 15.17-1.pgdg13+1))
Type "help" for help.

postgres=# \d pg_temp*.*
                Table "pg_temp_3.t"
 Column |  Type   | Collation | Nullable | Default
--------+---------+-----------+----------+---------
 id     | integer |           |          |

postgres=# SELECT * FROM pg_temp_3.t;
 id
----
(0 rows)


Since the table is indeed empty, the result is actually correct. But I'd
argue that we should raise an ERROR even if the table is empty. IMHO,
getting an error message or a "0 rows" result depending on the table row
count isn't ideal.

After populating the TEMPORARY TABLE the expected error message appears:

ERROR:  cannot access temporary tables of other sessions

Best, Jim




pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: ri_LockPKTuple misleading message
Next
From: Álvaro Herrera
Date:
Subject: Re: [PATCH] Compressed TOAST data corruption with REPACK CONCURRENTLY