From: | "Joel Jacobson" <joel(at)compiler(dot)org> |
---|---|
To: | "Michael Paquier" <michael(at)paquier(dot)xyz> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Missing free_var() at end of accum_sum_final()? |
Date: | 2023-02-16 07:08:37 |
Message-ID: | ebf7f18e-c9b6-4c4d-b0d1-47611e58f781@app.fastmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Feb 16, 2023, at 07:26, Michael Paquier wrote:
> Indeed, it is true that any code path of numeric.c that relies on a
> NumericVar with an allocation done in its buffer is careful enough to
> free it, except for generate_series's SRF where one step of the
> computation is done. I don't see directly why you could not do the
> following:
> @@ -11973,6 +11973,9 @@ accum_sum_final(NumericSumAccum *accum,
> NumericVar *result)
> /* And add them together */
> add_var(&pos_var, &neg_var, result);
>
> + free_var(&pos_var);
> + free_var(&neg_var);
> +
Thanks for looking and explaining.
I added the free_var() calls after strip_var() to match the similar existing code at the end of sqrt_var().
Not that it matters, but thought it looked nicer to keep them in the same order.
/Joel
Attachment | Content-Type | Size |
---|---|---|
numeric-accum-sum-final-free-var.patch | application/octet-stream | 392 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | tender wang | 2023-02-16 07:16:23 | wrong query result due to wang plan |
Previous Message | Jim Jones | 2023-02-16 07:08:16 | Re: [PATCH] Add pretty-printed XML output option |