Re: Avoid resource leak (src/bin/pg_dump/pg_dumpall.c) - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Avoid resource leak (src/bin/pg_dump/pg_dumpall.c)
Date
Msg-id e4abde63-4a66-45d3-8ecc-8931f6c6fc66@dunslane.net
Whole thread Raw
In response to Re: Avoid resource leak (src/bin/pg_dump/pg_dumpall.c)  (Álvaro Herrera <alvherre@kurilemu.de>)
Responses Re: Avoid resource leak (src/bin/pg_dump/pg_dumpall.c)
List 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




pgsql-hackers by date:

Previous
From: Bertrand Drouvot
Date:
Subject: Re: Use pg_icu_unicode_version(void) instead of pg_icu_unicode_version()
Next
From: Robert Haas
Date:
Subject: Re: pg_combinebackup: incorrect size of VM fork after combine