Re: pg_upgrade: fix memory leak in SLRU I/O code
| От | Chao Li |
|---|---|
| Тема | Re: pg_upgrade: fix memory leak in SLRU I/O code |
| Дата | |
| Msg-id | 5AF72017-4DBE-4837-BA50-54C3B0B8542E@gmail.com обсуждение исходный текст |
| Ответ на | Re: pg_upgrade: fix memory leak in SLRU I/O code (Michael Paquier <michael@paquier.xyz>) |
| Ответы |
Re: pg_upgrade: fix memory leak in SLRU I/O code
|
| Список | pgsql-hackers |
> On Feb 5, 2026, at 13:28, Michael Paquier <michael@paquier.xyz> wrote: > > On Thu, Feb 05, 2026 at 01:02:08PM +0800, Chao Li wrote: >> My concern is more about the pattern: freeing the container >> structure while leaving its members allocated. That feels >> inconsistent and potentially confusing to readers. Either owning >> objects should be fully freed, or not freed at all, but partial >> freeing doesn’t seem like a great precedent. I’m not sure that’s a >> pattern we want to encourage in PG code. > > For one-time allocations that are freed once we exit the binary, I > would not have bothered about freeing the state, Exactly. In this case, memory leaking is not a problem at all. My thinking was that once we do decide to free the top-levelobject, it feels more consistent and less surprising to also free what it owns, even if the lifetime is effectivelythe whole process. It’s less about resource pressure and more about keeping the ownership model clear for futurereaders and maintenance. TBH, I’ve been very careful about judging whether a memory-related issue is really worth patching, as I asked you about thisbefore. I think I used the wrong subject line here, the point isn’t about a memory leak at all. I understand the trade-off, and I’m happy to drop this if the consensus is that it’s not worth touching. Best regards, -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/
В списке pgsql-hackers по дате отправления: