Re: SlabCheck leaks memory into TopMemoryContext
От | Andres Freund |
---|---|
Тема | Re: SlabCheck leaks memory into TopMemoryContext |
Дата | |
Msg-id | 20200116064143.opcu2vhcktddpzbh@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: SlabCheck leaks memory into TopMemoryContext (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: SlabCheck leaks memory into TopMemoryContext
Re: SlabCheck leaks memory into TopMemoryContext |
Список | pgsql-hackers |
Hi, On 2020-01-16 01:25:00 -0500, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > On 2020-01-16 00:09:53 -0500, Tom Lane wrote: > >> It's basically assuming that the memory management mechanism is sane, > >> which makes the whole thing fundamentally circular, even if it's > >> relying on some other context to be sane. Is there a way to do the > >> checking without extra allocations? > > > Probably not easily. > > In the AllocSet code, we don't hesitate to expend extra space per-chunk > for debug support: > > typedef struct AllocChunkData > { > ... > #ifdef MEMORY_CONTEXT_CHECKING > Size requested_size; > #endif > ... > > I don't see a pressing reason why SlabContext couldn't do something > similar, either per-chunk or per-context, whatever makes sense. Well, what I suggested upthread, was to just have two globals like int slabcheck_freechunks_size; bool *slabcheck_freechunks; and realloc that to the larger size in SlabContextCreate() if necessary, based on the computed chunksPerBlock? I thought you were asking whether any additional memory could just be avoided... Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: