Re: Fix stale allocChunkLimit when recycling AllocSet

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

In response to

Browse pgsql-hackers by date

  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