Re: Missing free_var() at end of accum_sum_final()?

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Missing free_var() at end of accum_sum_final()?
Дата
Msg-id Y+7q7h+M8XSu4ohs@paquier.xyz
обсуждение исходный текст
Ответ на Re: Missing free_var() at end of accum_sum_final()?  (Andres Freund <andres@anarazel.de>)
Ответы Re: Missing free_var() at end of accum_sum_final()?  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Thu, Feb 16, 2023 at 01:35:54PM -0800, Andres Freund wrote:
> But why do we need it? Most SQL callable functions don't need to be careful
> about not leaking O(1) memory, the exception being functions backing btree
> opclasses.
>
> In fact, the detailed memory management often is *more* expensive than just
> relying on the calling memory context being reset.
>
> Of course, numeric.c doesn't really seem to have gotten that message, so
> there's a consistency argument here.

I don't know which final result is better.  The arguments go two ways:
1) Should numeric.c be simplified so as its memory structure with extra
pfree()s, making it more consistent with more global assumptions than
just this file?  This has the disadvantage of creating more noise in
backpatching, while increasing the risk of leaks if some of the
removed parts are allocated in a tight loop within the same context.
This makes memory management less complicated.  That's how I am
understanding your point.
2) Should the style within numeric.c be more consistent?  This is how
I am understanding this proposal.  As you quote, this makes memory
management more complicated (not convinced about that for the internal
of numerics?), while making the file more consistent.

At the end, perhaps that's not worth bothering, but 2) prevails when
it comes to the rule of making some code consistent with its
surroundings.  1) has more risks seeing how old this code is.
--
Michael

Вложения

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Normalization of utility queries in pg_stat_statements
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: BRIN indexes vs. SK_SEARCHARRAY (and preprocessing scan keys)