From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tomas Vondra <tv(at)fuzzy(dot)cz> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | SlabCheck leaks memory into TopMemoryContext |
Date: | 2020-01-16 04:41:19 |
Message-ID: | 20200116044119.g45f7pmgz4jmodxj@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Tomas,
I just noticed that having a slab context around in an assertion build
leads to performance degrading and memory usage going up. A bit of
poking revealed that SlabCheck() doesn't free the freechunks it
allocates.
It's on its own obviously trivial to fix.
But there's also this note at the top:
* NOTE: report errors as WARNING, *not* ERROR or FATAL. Otherwise you'll
* find yourself in an infinite loop when trouble occurs, because this
* routine will be entered again when elog cleanup tries to release memory!
which seems to be violated by doing:
/* bitmap of free chunks on a block */
freechunks = palloc(slab->chunksPerBlock * sizeof(bool));
I guess it'd be better to fall back to malloc() here, and handle the
allocation failure gracefully? Or perhaps we can just allocate something
persistently during SlabCreate()?
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Khandekar | 2020-01-16 04:42:24 | Re: Minimal logical decoding on standbys |
Previous Message | Mahendra Singh Thalor | 2020-01-16 04:41:16 | Re: [HACKERS] Block level parallel vacuum |