Re: pg_dump: fix memory leak

From: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: m(dot)korotkov(at)postgrespro(dot)ru, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_dump: fix memory leak
Date: 2025-08-29 09:52:31
Message-ID: 202508290952.h2d7mqhr56zp@alvherre.pgsql
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2025-Aug-29, Daniel Gustafsson wrote:

> > On 28 Aug 2025, at 16:14, m(dot)korotkov(at)postgrespro(dot)ru wrote:
> >
> > I have found a potential memory leak in src/bin/pg_dump/dumputils.c
> > in the function generate_restrict_key(). Memory is allocated to the
> > ret pointer if pg_strong_random returns false, and this leads to a
> > memory leak. I have replaced the allocation to avoid this leak.
>
> This is not actually a leak since the application will terminate
> immediately if a restrict key cannot be generated. If you inspect the
> callsites you will see this pattern:
>
> if (!restrict_key)
> restrict_key = generate_restrict_key();
> if (!restrict_key)
> pg_fatal("could not generate restrict key");

Hmm, this begs the question -- why do we make generate_restrict_key()
return NULL in that case? Maybe we should redefine its contract to be
that it either returns a valid key, or it calls pg_fatal(). Then
callers don't have to worry about it.

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joel Jacobson 2025-08-29 10:05:36 Re: Assert single row returning SQL-standard functions
Previous Message Pavel Stehule 2025-08-29 09:52:25 Re: Assert single row returning SQL-standard functions