From: Tom Lane <tgl@sss.pgh.pa.us>
To: exclusion@gmail.com
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18492: Adding a toasted column to a table with an inherited temp table fails with Assert
Date: Mon, 03 Jun 2024 13:50:22 -0400
Message-ID: <78902.1717437022@sss.pgh.pa.us> (raw)
In-Reply-To: <18492-c7a2634bf4968763@postgresql.org>
References: <18492-c7a2634bf4968763@postgresql.org>
PG Bug reporting form <noreply@postgresql.org> writes:
> The following script:
> echo "CREATE TABLE t (a int);" | psql
> echo "
> CREATE TEMP TABLE tt() INHERITS (t);
> select pg_sleep(1);
> " | psql &
> echo "
> select pg_sleep(0.1);
> ALTER TABLE t ADD COLUMN b text;
> " | psql
> triggers an assertion failure with the following stack trace:
> TRAP: failed Assert("isTempOrTempToastNamespace(relnamespace)"), File:
> "relcache.c", Line: 3619, PID: 1339672
I'm inclined to think that we should reject any ALTER TABLE on another
session's temp table. It could theoretically work in cases that don't
require touching the temp table's contents, but it has to fail in all
cases that do require that, and I don't really want that distinction
to be semantically visible. It's too implementation-dependent and
would be likely to act differently in different PG versions.
This example shows that the prohibition would also have to include
failing if an ALTER recurses to a child table that is another
session's temp table; but the same error occurs if you just try to
modify the other temp table directly. I did
Session 1:
regression=# create temp table mytemptable(f1 int);
CREATE TABLE
Session 2:
regression=# \d *.mytemptable
Table "pg_temp_60.mytemptable"
Column | Type | Collation | Nullable | Default
--------+---------+-----------+----------+---------
f1 | integer | | |
regression=# alter table pg_temp_60.mytemptable add column f2 int;
ALTER TABLE
regression=# alter table pg_temp_60.mytemptable add column f3 text;
server closed the connection unexpectedly
Even though the "add column f2 int" step went through, I think it's
too scary to allow that. I think we have, or might have in future,
optimizations that assume that a session's temp tables aren't modified
by other sessions.
(Note that this would have failed anyway if I weren't doing it as
superuser, because I wouldn't have had lookup permission in
pg_temp_60.)
regards, tom lane
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: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18492: Adding a toasted column to a table with an inherited temp table fails with Assert
In-Reply-To: <78902.1717437022@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox