> 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.
> It took me a few days to reduce this from actual code that was experiencing this. If I turn off JIT, the problem
goesaway. (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