po 15. 1. 2024 v 15:03 odesílatel Daniel Gustafsson <daniel@yesql.se> napsal:
> 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.
yes
> It took me a few days to reduce this from actual code that was experiencing this. If I turn off JIT, the problem goes away. (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?