Re: Oom on temp (un-analyzed table caused by JIT) V16.1

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Oom on temp (un-analyzed table caused by JIT) V16.1
Дата
Msg-id CAFj8pRC+-bGOioevnUGweEU=-PubAL=PpFB0JQR+KFp4+H7e-Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Oom on temp (un-analyzed table caused by JIT) V16.1  (Daniel Gustafsson <daniel@yesql.se>)
Список pgsql-hackers


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?

    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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Make attstattarget nullable
Следующее
От: vignesh C
Дата:
Сообщение: Re: Rework LogicalOutputPluginWriterUpdateProgress