From: Tom Lane <tgl@sss.pgh.pa.us>
To: s.shinderuk@postgrespro.ru
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17669: Invalid TOAST pointer in PL/pgSQL variable
In-reply-to: <17669-2238da15dce5c53c@postgresql.org>
References: <17669-2238da15dce5c53c@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Thu, 27 Oct 2022 19:45:14 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1195624.1666964580.1@sss.pgh.pa.us>
Date: Fri, 28 Oct 2022 09:43:00 -0400
Message-ID: <1195625.1666964580@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1195625.1666964580%40sss.pgh.pa.us>
Precedence: bulk

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