Hello,
thanks for the information and the link!
Ales
čt 4. 8. 2022 v 1:05 odesílatel Tom Lane <tgl@xxxxxxxxxxxxx> napsal:
=?UTF-8?B?QWxlxaEgWmVsZW7DvQ==?= <zeleny.ales@xxxxxxxxx> writes:
> CREATE OR REPLACE FUNCTION tescase (_id_data_provider integer, _external_id
> bigint DEFAULT NULL::bigint, _external_complete_id character varying
> DEFAULT NULL::character varying)
> RETURNS TABLE(id_gm bigint, id_opp bigint, id_opp_state integer)
> LANGUAGE sql
> AS $function$
> SELECT ... simple join of two tables...
> WHERE opd.id_data_provider = _id_data_provider
> AND CASE WHEN _external_id IS NULL
> THEN external_id IS NULL
> ELSE external_id = _external_id
> END
> AND CASE WHEN _external_complete_id IS NULL
> THEN _external_complete_id IS NULL
> ELSE external_complete_id = _external_complete_id
> END;
> $function$
> ;
> It is a kind of creative construct for me, but it works. The key here is
> that if I replace at least one of the "CASEd" where conditions, it seems
> not to suffer from the memory leak issue.
> Finally, I've found, that even having the function as is and before the
> test disabling JIT (SET jit = off;) and calling the function 100k times,
> RssAnon memory for the given process is stable and only 3612 kB, while when
> JIT is enabled (the default setting on the server suffering from the memory
> leak, RssAnon memory for the given process growth in a linear manner over
> time (canceled when it reached 5GB).
Ah. I bet this is another instance of the known memory leakage problems
with JIT inlining [1]. Per Andres' comments in that thread, it seems
hard to solve properly. For now all I can recommend is to disable that.
regards, tom lane
[1] https://www.postgresql.org/message-id/flat/20201001021609.GC8476%40telsasoft.com
