Re: Missing free_var() at end of accum_sum_final()? - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Missing free_var() at end of accum_sum_final()?
Date
Msg-id Y+7q7h+M8XSu4ohs@paquier.xyz
Whole thread Raw
In response to Re: Missing free_var() at end of accum_sum_final()?  (Andres Freund <andres@anarazel.de>)
Responses Re: Missing free_var() at end of accum_sum_final()?
List 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

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Normalization of utility queries in pg_stat_statements
Next
From: Tomas Vondra
Date:
Subject: Re: BRIN indexes vs. SK_SEARCHARRAY (and preprocessing scan keys)