BUG #17669: Invalid TOAST pointer in PL/pgSQL variable
The following bug has been logged on the website:
Bug reference: 17669
Logged by: Sergey Shinderuk
Email address: s.shinderuk@postgrespro.ru
PostgreSQL version: 15.0
Operating system: Ubuntu 22.04
Description:
Is it a bug or a known limitation?
create table t (a int, b text);
alter table t alter column b set storage external;
insert into t values (1, repeat('a',3000));
create function f() returns text as $$
declare
s text;
begin
select b into s from t where a = 1;
truncate t;
return s;
end;
$$ language plpgsql;
postgres=# select f();
ERROR: missing chunk number 0 for toast value 24727 in pg_toast_24722
If I replace "truncate" with "drop table", then I get:
ERROR: could not open relation with OID 24725
With "delete from t" it just works.
PG Bug reporting form <noreply@postgresql.org> writes:
create function f() returns text as $$
declare
s text;
begin
select b into s from t where a = 1;
truncate t;
return s;
end;
$$ language plpgsql;
postgres=# select f();
ERROR: missing chunk number 0 for toast value 24727 in pg_toast_24722
To prevent that, every fetch into a plpgsql variable would have
to immediately detoast the value, in case somebody did something
as weird as dropping/truncating the table later in the function.
That's an awfully expensive bit of protection. We do in fact
do it like that in procedures (more specifically, in non-atomic
contexts), so a possible workaround for you is to make this a
procedure not a function. I'm disinclined to change it otherwise.
regards, tom lane
On 28.10.2022 16:43, Tom Lane wrote:
PG Bug reporting form <noreply@postgresql.org> writes:
postgres=# select f();
ERROR: missing chunk number 0 for toast value 24727 in pg_toast_24722To prevent that, every fetch into a plpgsql variable would have
to immediately detoast the value, in case somebody did something
as weird as dropping/truncating the table later in the function.
That's an awfully expensive bit of protection. We do in fact
do it like that in procedures (more specifically, in non-atomic
contexts), so a possible workaround for you is to make this a
procedure not a function. I'm disinclined to change it otherwise.
Thank you for explaining.
--
Sergey Shinderuk https://postgrespro.com/