Re: memory leak in trigger handling (since PG12)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: memory leak in trigger handling (since PG12)
Дата
Msg-id 965727.1684862910@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: memory leak in trigger handling (since PG12)  (Andres Freund <andres@anarazel.de>)
Ответы Re: memory leak in trigger handling (since PG12)  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> I've wondered about some form of instrumentation to detect such issues
> before.

Yeah.

> Could it help to have a mode where the executor shutdown hook checks how much
> memory is allocated in ExecutorState and warns if its too much?

It'd be very hard to set a limit for what's "too much", since the amount
of stuff created initially will depend on the plan size.  In any case
I think that the important issue is not how much absolute space, but is
there per-row leakage.  I wonder if we could do something involving
checking for continued growth after the first retrieved tuple, or
something like that.

> Random aside: I've been wondering whether it'd be worth introducing an
> in-place representation of Bitmap (e.g. if the low bit is set, the low 63 bits
> are in-place, if unset, it's a pointer).

Why?  Unlike Lists, those things are already a single palloc chunk.

            regards, tom lane



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: memory leak in trigger handling (since PG12)
Следующее
От: "Tristan Partin"
Дата:
Сообщение: Use COPY for populating all pgbench tables