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?
