Re: [BUG] plpgsql RETURN QUERY with toasted fields -vs- DROP/TRUNCATE

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: [BUG] plpgsql RETURN QUERY with toasted fields -vs- DROP/TRUNCATE
Date: 2020-08-29 17:47:19
Message-ID: 3568911.1598723239@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com> writes:
> We discovered a bug in plpgsql.
> When using RETURN QUERY on a relation with some toasted values and when this
> relaiton is later dropped or truncated, an error is raised at the end of the
> function.

This isn't particularly RETURN QUERY's fault; there are any number of ways
to produce the same sort of error. I reproduced it with

declare r record;
...
for r in SELECT str FROM temp_rel loop
return next r.str;
end loop;

as well as

declare r record;
...
SELECT str INTO r FROM temp_rel LIMIT 1;

DROP TABLE temp_rel;
--TRUNCATE TABLE temp_rel;

return r.str;

I guess we could forcibly detoast values in enough places to close all the
gaps, but the performance costs might be annoying. I think a case can
definitely be made for saying "don't do that".

(Another idea, perhaps, might be to detoast only in volatile functions,
reasoning that a nonvolatile one can't drop the table.)

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Alexander Korotkov 2020-08-30 01:44:58 Re: BUG #16592: websearch_to_tsquery() returns queries that don't result in expected matches
Previous Message Michael Paquier 2020-08-29 01:34:33 Re: BUG #16594: DROP INDEX CONCURRENTLY fails on partitioned table with a non helpful error message.