From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Tomas Vondra <tv(at)fuzzy(dot)cz>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SlabCheck leaks memory into TopMemoryContext |
Date: | 2020-01-16 06:41:43 |
Message-ID: | 20200116064143.opcu2vhcktddpzbh@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2020-01-16 01:25:00 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2020-01-16 06:50:02 | Re: Append with naive multiplexing of FDWs |
Previous Message | Tom Lane | 2020-01-16 06:25:00 | Re: SlabCheck leaks memory into TopMemoryContext |