| From: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | yangyz <1197620467(at)qq(dot)com>, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Avoid resource leak (src/bin/pg_dump/pg_dumpall.c) |
| Date: | 2026-03-09 05:28:32 |
| Message-ID: | A79CC144-D831-42FA-AF6A-AB548F13AE45@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On Mar 9, 2026, at 12:17, Michael Paquier <michael(at)paquier(dot)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/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Henson Choi | 2026-03-09 05:41:12 | Re: Accounting for metapages in genericcostestimate() |
| Previous Message | Peter Smith | 2026-03-09 05:22:36 | Re: Use allocation macros in the logical replication code |