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

On Mon, Jan 15, 2024 at 9:03 AM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:

> > 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.
>

The script starts by creating 90 Million rows... In my world that part of
the script, plus the indexes, etc. Takes about 8-9 minutes.
And has no memory loss.

I used the memory reported by HTOP to track the problem. I Forgot to
mention this.
I am curious what you used? (Because it doesn't display symptoms [running
dog slow] until the backend has about 85% of the machines memory)

> 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/

Thank you. I have assigned that task to the guy who maintains our
VMs/Environments.
I will report back to you.

Kirk