Re: Fix stale allocChunkLimit when recycling AllocSet

From: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
To: Donghang Lin <donghanglin(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fix stale allocChunkLimit when recycling AllocSet
Date: 2026-10-19 06:03:54
Message-ID: 6058C586-4A0F-4910-96B9-623A0ECE67B3@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Oct 17, 2026, at 08:47, Donghang Lin <donghanglin(at)gmail(dot)com> wrote:
>
> 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.

Thanks a lot for your review.

>
>> 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.

Yes, that’s another consequence of stale larger allocChunkLimit.

>
>> 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.
>

Cool!

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2026-10-19 06:20:19 Re: Publication of same parent table with ONLY-ness mismatch should error
Previous Message Chao Li 2026-10-19 05:53:42 Re: [PATCH v1] Fix tab completion for DROP INDEX CONCURRENTLY