| From: | Donghang Lin <donghanglin(at)gmail(dot)com> |
|---|---|
| To: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Fix stale allocChunkLimit when recycling AllocSet |
| Date: | 2026-10-17 00:47:02 |
| Message-ID: | CAA=D8a3hBfaU1tzBoSUFGQLReXDo-Va2N3Z7cWHzLyE4ujdEyg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Chao,
> When recycling a context from the freelist, it only resets set->maxBlockSize without recalculating set->allocChunkLimit, while set->allocChunkLimit is derived from set->maxBlockSize.
Nice find! It's clear that the reuse path diverges from the create
path for setting allocChunkLimit.
> In summary, this bug doesn’t lead to memory leaks, but it breaks AllocSet’s intended allocation behavior: sometimes causing unexpected malloc()/free() calls, and sometimes unexpected pooling and memory retention.
Per the comment you moved to the helper function, if allocChunkLimit
doesn't follow the ALLOC_CHUNK_FRACTION formula, it could also lead to
unexpected size of memory waste at a block's tail.
> The fix is straightforward. I extracted the allocChunkLimit computation into a shared helper and use it in both the creation and recycling paths. See the attached patch for details. Since this code is very old, the fix might be worth backpatching to all supported branches.
The fix looks good to me.
Regards,
Donghang
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Langote | 2026-10-17 01:36:57 | Re: Two more RI fast-path issues |
| Previous Message | Masahiko Sawada | 2026-10-17 00:27:17 | Re: [PG19] Promotion hangs behind a backend blocked on a stuck client |