Re: Avoid resource leak (src/bin/pg_dump/pg_dumpall.c)
| От | Chao Li |
|---|---|
| Тема | Re: Avoid resource leak (src/bin/pg_dump/pg_dumpall.c) |
| Дата | |
| Msg-id | 9B3571BB-0585-4171-83F1-46761F06FA11@gmail.com обсуждение исходный текст |
| Ответ на | Avoid resource leak (src/bin/pg_dump/pg_dumpall.c) (Ranier Vilela <ranier.vf@gmail.com>) |
| Ответы |
Re: Avoid resource leak (src/bin/pg_dump/pg_dumpall.c)
|
| Список | 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 frontendprocess, 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/
В списке pgsql-hackers по дате отправления: