Re: Avoid resource leak (src/bin/pg_dump/pg_dumpall.c)
Ranier Vilela <ranier.vf@gmail.com>
From: Ranier Vilela <ranier.vf@gmail.com>
To: Álvaro Herrera <alvherre@kurilemu.de>
Cc: Michael Paquier <michael@paquier.xyz>, yangyz <1197620467@qq.com>, Chao Li <li.evan.chao@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2026-03-09T12:54:20Z
Lists: pgsql-hackers
Em seg., 9 de mar. de 2026 às 09:40, Álvaro Herrera <alvherre@kurilemu.de>
escreveu:
> 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.
>
+1
LGTM.
best regards,
Ranier Vilela
>
> --
> Álvaro Herrera 48°01'N 7°57'E —
> https://www.EnterpriseDB.com/
> "Just treat us the way you want to be treated + some extra allowance
> for ignorance." (Michael Brusser)
>
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
pg_dumpall: simplify coding of dropDBs()
- a198c26dede5 19 (unreleased) landed