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/
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 |