| 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: | Whole Thread | Raw Message | 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 |