| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Álvaro Herrera <alvherre(at)kurilemu(dot)de>, Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | yangyz <1197620467(at)qq(dot)com>, Chao Li <li(dot)evan(dot)chao(at)gmail(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 16:41:03 |
| Message-ID: | e4abde63-4a66-45d3-8ecc-8931f6c6fc66@dunslane.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2026-03-09 Mo 8:40 AM, Álvaro Herrera wrote:
> On 2026-Mar-09, Michael Paquier 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.
> True, but at the same time it looks as if this routine is wastefully
> written -- I mean, why spend time with a stringinfo here at all? We
> could write this in much simpler form, as in the attached, which is even
> three lines shorter. In fact, before 763aaa06f034, this is exactly how
> this routine was written, and I don't see why it was changed this way.
>
I forget why, but your change looks good. Do you want to apply it?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2026-03-09 16:48:38 | Re: pg_combinebackup: incorrect size of VM fork after combine |
| Previous Message | Bertrand Drouvot | 2026-03-09 16:41:01 | Re: Use pg_icu_unicode_version(void) instead of pg_icu_unicode_version() |