| 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: | Whole Thread | Raw Message | 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 |