Thread

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

Kirk Wolak <wolakk@gmail.com> — 2024-01-15T15:49:19Z

On Mon, Jan 15, 2024 at 9:03 AM Daniel Gustafsson <daniel@yesql.se> wrote:

> > On 15 Jan 2024, at 07:24, Kirk Wolak <wolakk@gmail.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