I wrote:
> BTW, it occurs to me to wonder whether we need to worry about such
> subsidiary leaks in type input functions as well.
Sure enough, once you find an input function that leaks memory, there's
trouble:
create type myrow as (f1 text, f2 text, f3 text);
create or replace function leak_ass
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
> While chasing a PL/Python memory leak, I did a few tests with PL/pgSQL
> and I think there are places where memory is not freed sufficiently early.
I think the basic issue here is that the type output function might
generate (and not bother to free) addi
While chasing a PL/Python memory leak, I did a few tests with PL/pgSQL
and I think there are places where memory is not freed sufficiently early.
Attached are two functions that when run will make the backend's memory
consumption increase until they finish. With both, the cause is
convert_value_to
