Re: pg_upgrade: fix memory leak in SLRU I/O code
| От | Dilip Kumar |
|---|---|
| Тема | Re: pg_upgrade: fix memory leak in SLRU I/O code |
| Дата | |
| Msg-id | CAFiTN-v2y0AV5YNeG5aTaupi_5+HKGw-gXtFuV3ixYpqSW_iwQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | pg_upgrade: fix memory leak in SLRU I/O code (Chao Li <li.evan.chao@gmail.com>) |
| Список | pgsql-hackers |
On Wed, Feb 4, 2026 at 2:51 PM Chao Li <li.evan.chao@gmail.com> wrote:
>
> Hi Hackers,
>
> This comes from a previous review and has been on my to-do list for a while.
>
> Since src/bin/pg_upgrade/slru_io.c includes postgres_fe.h, it is frontend code, so backend memory contexts are not
usedhere.
>
> In the current code:
> ```
> void
> FreeSlruWrite(SlruSegState *state)
> {
> Assert(state->writing);
>
> SlruFlush(state);
>
> if (state->fd != -1)
> close(state->fd);
> pg_free(state);
> }
> ```
>
> the SlruSegState itself is freed, but state->dir and state->fn are not, which results in a memory leak during
pg_upgraderuns. More generally, I don’t see a reason to free an object itself without also freeing the memory owned by
itsmembers.
>
> While looking at this, I also noticed that state->dir is allocated using pstrdup(). To better align with frontend
conventions,the patch switches this to pg_strdup() and introduces a common cleanup helper to free all resources
associatedwith SlruSegState.
>
> See the attached patch.
The patch LGTM, just one suggestion, adds a one liner comment over the
new function[1] for consistency.
[1]
+static void
+FreeSlruSegState(SlruSegState *state)
+{
+ if (state->fd != -1)
+ close(state->fd);
+
+ pg_free(state->fn);
+ pg_free(state->dir);
+ pg_free(state);
+}
--
Regards,
Dilip Kumar
Google
В списке pgsql-hackers по дате отправления: