Re: Oom on temp (un-analyzed table caused by JIT) V16.1

po 15. 1. 2024 v 15:03 odesílatel Daniel Gustafsson <daniel(at)yesql(dot)se>
napsal:

> > On 15 Jan 2024, at 07:24, Kirk Wolak <wolakk(at)gmail(dot)com> wrote:
>
> > You have a commit [1] that MIGHT fix this.
> > I have a script that recreates the problem, using random data in pg_temp.
> > And a nested cursor.
>
> Running your reproducer script in a tight loop for a fair bit of time on
> the
> v16 HEAD I cannot see any memory growth, so it's plausible that the
> upcoming
> 16.2 will work better in your environment.
>

yes

>
> > It took me a few days to reduce this from actual code that was
> experiencing this. If I turn off JIT, the problem goes away. (if I don't
> FETCH the first row, the memory loss does not happen. Maybe because
> opening a cursor is more decoration/prepare)
> >
> > I don't have an easy way to test this script right now against the
> commit.
>
> There are up to date snapshots of the upcoming v16 minor release which
> might
> make testing easier than building postgres from source?
>
> https://www.postgresql.org/download/snapshots/
>
> Admittedly I don't know whether those are built with LLVM support but I
> think
> they might be.
>
> > I am hopeful that your fix fixes this.
>
> It seems likely, so it would be very valuable if you could try running the
> pre
> -release version of v16 before 16.2 ships to verify this.
>
> --
> Daniel Gustafsson
>
>