| From: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
|---|---|
| To: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> |
| Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Avoid resource leak (src/bin/pg_dump/pg_dumpall.c) |
| Date: | 2026-03-09 00:04:54 |
| Message-ID: | 9B3571BB-0585-4171-83F1-46761F06FA11@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On Mar 9, 2026, at 07:05, Ranier Vilela <ranier(dot)vf(at)gmail(dot)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/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2026-03-09 00:07:04 | Re: Add expressions to pg_restore_extended_stats() |
| Previous Message | Mihail Nikalayeu | 2026-03-09 00:03:00 | Re: Resetting snapshots during the first phase of [CREATE |RE]INDEX CONCURRENTLY |