On Mon, Jan 15, 2024 at 9:03 AM Daniel Gustafsson <dan...@yesql.se> wrote:
> > On 15 Jan 2024, at 07:24, Kirk Wolak <wol...@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
