Re: Avoid resource leak (src/bin/pg_dump/pg_dumpall.c)

Chao Li <li.evan.chao@gmail.com>

From: Chao Li <li.evan.chao@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: yangyz <1197620467@qq.com>, Ranier Vilela <ranier.vf@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2026-03-09T05:28:32Z
Lists: pgsql-hackers

> On Mar 9, 2026, at 12:17, Michael Paquier <michael@paquier.xyz> wrote:
> 
> On Mon, Mar 09, 2026 at 11:21:35AM +0800, yangyz wrote:
>> I think it should be modified.
>> 
>> Move createPQExpBuffer inside the conditional block to match its destroy counterpart.
>> This improves code clarity and satisfies static analyzers, even though the actual memory
>> leak is minimal in practice.
> 
> destroyPQExpBuffer() is called for each tuple from pg_database except
> if dealing with "template{0,1}" or "postgres".  It means that we would
> just leak a few bytes for these three cases.  I agree that the
> variable declaration can be placed better, but it's really not worth
> bothering in this context.
> --
> Michael

Hi Michael,

From a memory-leak perspective, this is certainly a very minor issue. Still, I think the current placement hurts the code quality a bit, even if the runtime impact is tiny.

If this patch feels too trivial to take separately, perhaps it could be pushed into your bi-monthly stack.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/







Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. pg_dumpall: simplify coding of dropDBs()