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
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. |