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: Ranier Vilela <ranier.vf@gmail.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2026-03-09T00:04:54Z
Lists: pgsql-hackers

> On Mar 9, 2026, at 07:05, Ranier Vilela <ranier.vf@gmail.com> wrote:
> 
> Hi.
> 
> Per Coverity.
> 
> Coverity complains about one resource leak in the function
> *drops_DBs*.
> 
> CID 1645454: (#1 of 1): Resource leak (RESOURCE_LEAK) 
> 19. leaked_storage: Variable delQry going out of scope leaks the storage it points to.
> 
> Fix by avoiding creating the buffer unnecessarily.
> 
> Trivial patch attached.
> 
> best regards,
> Ranier Vilela
> <avoid-resource-leak-pg_dumpall.patch>

I confirmed this is a leak, but only leaks 3 tuples, not much memory leaked. Given pg_dump call is not a long-live frontend process, such leak won’t hurt much.

Instead of claiming a memory leak, I would tend to claim a logic mistake. Because createPQExpBuffer is before the “if” clause, but the corresponding destroyPQExpBuffer is placed inside the “if” clause, they are logically mismatch.

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()