Re: Silence resource leaks alerts - Mailing list pgsql-hackers

From Ranier Vilela
Subject Re: Silence resource leaks alerts
Date
Msg-id CAEudQAqpiOH8cKbZ5Y_aTRhOXNu7TCE-B7ZMpZa9TVA+k4v_ew@mail.gmail.com
Whole thread Raw
In response to Re: Silence resource leaks alerts  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Silence resource leaks alerts
List pgsql-hackers
Thanks Michael, for looking at this.


Em sex., 11 de abr. de 2025 às 02:09, Michael Paquier <michael@paquier.xyz> escreveu:
On Thu, Apr 10, 2025 at 03:10:02PM -0300, Ranier Vilela wrote:
> While it is arguable that this is a false warning, there is a benefit in
> moving the initialization of the string buffer, silencing the warnings that
> are presented in this case.
>
> 1. pg_overexplain.c
> 2. ruleutils.c

These code paths are far from being critical and the two ones in
ruleutils.c are older, even if it is a practice that had better be
discouraged particularly as initStringInfo() can allocate some memory
for nothing.  So it could bloat the current memory context if these
code paths are repeatedly taken.
Yeah, it's a bit annoying to do unnecessary work.
Plus a small gain, by delaying memory allocation until when it is actually needed.


FWIW, I'm with these changes to delay these initializations as you are
proposing.
Thanks.
 
  The RMT has a say about such changes post feature-freeze,
though, even if the one in pg_overexplain.c is new to v18.
I agree.

best regards,
Ranier Vilela

pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Prevent an error on attaching/creating a DSM/DSA from an interrupt handler.
Next
From: Robert Haas
Date:
Subject: Re: Add pg_buffercache_evict_all() and pg_buffercache_mark_dirty[_all]() functions