Re: Silence resource leaks alerts

From: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Silence resource leaks alerts
Date: 2025-04-11 11:27:23
Message-ID: CAEudQAqpiOH8cKbZ5Y_aTRhOXNu7TCE-B7ZMpZa9TVA+k4v_ew@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thanks Michael, for looking at this.

Em sex., 11 de abr. de 2025 às 02:09, Michael Paquier <michael(at)paquier(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2025-04-11 11:43:38 Re: Add pg_buffercache_evict_all() and pg_buffercache_mark_dirty[_all]() functions
Previous Message Daniel Gustafsson 2025-04-11 10:23:53 Re: Prevent an error on attaching/creating a DSM/DSA from an interrupt handler.