Thread: 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_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.
Thank you for explaining.

-- 
Sergey Shinderuk        https://postgrespro.com/