| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
| Cc: | Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>, 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 04:37:19 |
| Message-ID: | aYQefwYTPypf5yZU@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Feb 05, 2026 at 12:02:51PM +0800, Chao Li wrote:
> Thank you very much for the review. Yes, the leak itself is tiny,
> the main point for me is that the memory owned by the struct members
> is not freed, which can be a bit confusing for code readers. As for
> the change from pstrdup() to pg_strdup(), that felt too trivial to
> justify a separate patch, so I took this as an opportunity to clean
> it up at the same time.
Does it really matter memory-wise? Even in the case of state->fn,
SlruReadSwitchPageSlow() and SlruWriteSwitchPageSlow() make sure to
free it before switching to a new segment to process, and these state
allocations are done once. Well, okay, twice as of the members *and*
the offsets, but the logic as written is not going to bloat memory
with a short loop execution.
In short, I see nothing worth changing.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Shinya Kato | 2026-02-05 04:39:27 | Re: Report oldest xmin source when autovacuum cannot remove tuples |
| Previous Message | Hayato Kuroda (Fujitsu) | 2026-02-05 04:19:48 | RE: logical apply worker's lock waits in subscriber can stall checkpointer in publisher |