On Tue, Jan 16, 2024 at 3:43 AM Daniel Gustafsson <dan...@yesql.se> wrote:
> > On 16 Jan 2024, at 02:53, Kirk Wolak <wol...@gmail.com> wrote: > > > > On Mon, Jan 15, 2024 at 9:03 AM Daniel Gustafsson <dan...@yesql.se > <mailto:dan...@yesql.se>> wrote: > > > On 15 Jan 2024, at 07:24, Kirk Wolak <wol...@gmail.com <mailto: > wol...@gmail.com>> wrote: > >... > > Okay, I took the latest source off of git (17devel) and got it to work > there in a VM. > > > > It appears this issue is fixed. It must have been related to the issue > originally tagged. > > Thanks for testing and confirming! Testing pre-release builds on real life > workloads is invaluable for the development of Postgres so thank you > taking the > time. Daniel, I did a little more checking and the reason I did not see the link MIGHT be because EXPLAIN did not show a JIT attempt. I tried to use settings that FORCE a JIT... But to no avail. I am now concerned that the problem is more hidden in my use case. Meaning I CANNOT conclude it is fixed. But I know of NO WAY to force a JIT (I lowered costs to 1, etc. ). You don't know a way to force at least the JIT analysis to happen? (because I already knew if JIT was off, the leak wouldn't happen). Thanks, Kirk Out! PS: I assume there is no pg_jit(1) function I can call. LOL
