| From: | Álvaro Herrera <alvherre(at)kurilemu(dot)de> |
|---|---|
| To: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, 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 10:25:54 |
| Message-ID: | 202602051024.2j4dpyfy22zr@alvherre.pgsql |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2026-Feb-05, Chao Li wrote:
> Exactly. In this case, memory leaking is not a problem at all. My
> thinking was that once we do decide to free the top-level object, it
> feels more consistent and less surprising to also free what it owns,
> even if the lifetime is effectively the whole process. It’s less about
> resource pressure and more about keeping the ownership model clear for
> future readers and maintenance.
Maybe we should just change the "pg_free(state)" to "/* no point freeing
memory */" or something like that.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"We're here to devour each other alive" (Hobbes)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2026-02-05 10:28:00 | Re: Small fixes for incorrect error messages |
| Previous Message | Álvaro Herrera | 2026-02-05 10:22:19 | Re: Truncate logs by max_log_size |