From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Reid Thompson <reid(dot)thompson(at)crunchydata(dot)com>, 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 18:23:47 |
Message-ID: | 20220729182347.GA416716@nathanxps13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jul 29, 2022 at 01:55:10PM -0400, Tom Lane wrote:
> Nathan Bossart <nathandbossart(at)gmail(dot)com> writes:
>> 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.
>
>> IIUC this is because the header is tracked separately from the first
>> regular block, unlike aset.c.
>
> That doesn't make it not an oversight, though. It looks like aset.c
> thinks that mem_allocated includes all the context's overhead, whereas
> this implementation doesn't seem to have that result. The comments
> associated with mem_allocated are sufficiently vague that it's impossible
> to tell which implementation is correct. Maybe we don't really care,
> but ...
Hm. mmgr/README indicates the following note about mem_allocated:
* inquire about the total amount of memory allocated to the context
(the raw memory from which the context allocates chunks; not the
chunks themselves)
AFAICT MemoryContextMemAllocated() is only used for determining when to
spill to disk for hash aggegations at the moment. I don't know whether I'd
classify this as an oversight or if it even makes any meaningful
difference, but consistency among the different implementations is probably
desirable either way. So, I guess I'm +1 for including the memory context
header in mem_allocated in this case.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2022-07-29 18:27:36 | Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size |
Previous Message | Alvaro Herrera | 2022-07-29 18:12:53 | Re: making relfilenodes 56 bits |