Re: plpgsql memory leaks - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: plpgsql memory leaks
Date
Msg-id CAFj8pRCMjozEaBxuLRXB50CYkPoui4WtbX6XaRKvOYPp+76Zcg@mail.gmail.com
Whole thread Raw
In response to Re: plpgsql memory leaks  (Michael Banck <mbanck@gmx.net>)
Responses Re: plpgsql memory leaks
List pgsql-hackers


pá 12. 1. 2024 v 14:53 odesílatel Michael Banck <mbanck@gmx.net> napsal:
Hi,

On Fri, Jan 12, 2024 at 01:35:24PM +0100, Pavel Stehule wrote:
> pá 12. 1. 2024 v 11:54 odesílatel Michael Banck <mbanck@gmx.net> napsal:
> > Which version of Postgres is this and on which platform/distribution?
>
> It was tested on master branch (pg 17) on Fedora 39
>
> > Did you try keep jit on but set jit_inline_above_cost to 0?
> >
> > The back-branches have a fix for the above case, i.e. llvmjit memleaks
> > that can be worked-around by setting jit_inline_above_cost=0.

I got that wrong, it needs to be -1 to disable it.

But if you are already running the master branch, it is probably a
separate issue.

I tested code

CREATE OR REPLACE FUNCTION public.fx(iter integer)
 RETURNS void
 LANGUAGE plpgsql
AS $function$
declare
  c cursor(m bigint) for select distinct i from generate_series(1, m) g(i);
  t bigint;
  s bigint;
begin
  for i in 1..iter
  loop
    s := 0;
    for r in c(i*10000)
    loop
      s := s + r.i;
    end loop;
    raise notice '%=%', i, s;
  end loop;
end;
$function$

default master branch - res 190MB ram
jit_inline_above_cost = -1 doesn't helps
disabling JIT doesn't helps too,

so it looks like the wrong hypothesis , and the problem is maybe somewhere else :-/

Regards

Pavel

 


Michael

pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: Confine vacuum skip logic to lazy_scan_skip
Next
From: Melanie Plageman
Date:
Subject: Re: Confine vacuum skip logic to lazy_scan_skip