From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | s(dot)shinderuk(at)postgrespro(dot)ru |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17669: Invalid TOAST pointer in PL/pgSQL variable |
Date: | 2022-10-28 13:43:00 |
Message-ID: | 1195625.1666964580@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
PG Bug reporting form <noreply(at)postgresql(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Sergey Shinderuk | 2022-10-28 14:16:02 | Re: BUG #17669: Invalid TOAST pointer in PL/pgSQL variable |
Previous Message | PG Bug reporting form | 2022-10-28 07:48:50 | BUG #17670: Logical Replication data may be lost on the subscription under certain scenarios |