Re: Oversight in slab.c SlabContextCreate(), initial memory allocation size is not populated to context->mem_allocated

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Reid Thompson <reid(dot)thompson(at)crunchydata(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Oversight in slab.c SlabContextCreate(), initial memory allocation size is not populated to context->mem_allocated
Date: 2022-07-29 17:48:40
Message-ID: 20220729174840.GA415763@nathanxps13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 29, 2022 at 12:43:45PM -0400, Reid Thompson wrote:
> slab.c
> does not in SlabContextCreate(). Is this intentional, it seems to be an
> oversight to me.
>
> /* Finally, do the type-independent part of context creation */
> MemoryContextCreate((MemoryContext) slab,
> T_SlabContext,
> &SlabMethods,
> parent,
> name);
>
> return (MemoryContext) slab;
> }

IIUC this is because the header is tracked separately from the first
regular block, unlike aset.c. See the following comment:

/*
* Allocate the context header. Unlike aset.c, we never try to combine
* this with the first regular block; not worth the extra complication.
*/

You'll also notice that the "reset" and "free" functions in aset.c and
generation.c have special logic for "keeper" blocks. Here is a relevant
comment from AllocSetReset():

* Actually, this routine has some discretion about what to do.
* It should mark all allocated chunks freed, but it need not necessarily
* give back all the resources the set owns. Our actual implementation is
* that we give back all but the "keeper" block (which we must keep, since
* it shares a malloc chunk with the context header). In this way, we don't
* thrash malloc() when a context is repeatedly reset after small allocations,
* which is typical behavior for per-tuple contexts.

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-07-29 17:49:12 Re: pg15b2: large objects lost on upgrade
Previous Message Robert Haas 2022-07-29 17:24:50 Re: making relfilenodes 56 bits