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.
If this function is reused in the future or used in long-lived processes, it might become a problem.
Regards,
Yuanzhuo Yang
From: Chao Li <li.evan.chao@gmail.com> Date: 2026-03-09 08:04 To: Ranier Vilela <ranier.vf@gmail.com> Cc: Pg Hackers <pgsql-hackers@postgresql.org> Subject: Re: Avoid resource leak (src/bin/pg_dump/pg_dumpall.c) |
> 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/
