po 15. 1. 2024 v 15:03 odesÃlatel Daniel Gustafsson <dan...@yesql.se> napsal:
> > 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. > 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? > > 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 > >
