| From: | Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp> |
|---|---|
| To: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
| Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pg_upgrade: fix memory leak in SLRU I/O code |
| Date: | 2026-02-05 01:54:33 |
| Message-ID: | 20260205105433.9fcc5f980241bb35a6517448@sraoss.co.jp |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 4 Feb 2026 17:20:49 +0800
Chao Li <li(dot)evan(dot)chao(at)gmail(dot)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 used here.
>
> 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_upgrade runs. More generally, I don’t see a reason to free an object itself without also freeing the memory owned by its members.
As far as I know, AllocSlruSegState() and FreeSlruWrite() are not called
repeatedly in a loop, and the amount of memory involved is small, so the
impact of the leak seems limited. That said, I agree that it is better to
also free the memory owned by the struct members.
Regards,
Yugo Nagata
>
> 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 associated with SlruSegState.
>
> See the attached patch.
>
> Best regards,
> --
> Chao Li (Evan)
> HighGo Software Co., Ltd.
> https://www.highgo.com/
>
>
>
>
--
Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2026-02-05 02:17:45 | Re: Truncate logs by max_log_size |
| Previous Message | Tatsuo Ishii | 2026-02-05 01:25:19 | Re: Row pattern recognition |