From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: hyrax vs. RelationBuildPartitionDesc |
Date: | 2019-03-15 07:32:22 |
Message-ID: | 2efba7eb-7fab-59db-68bd-9a03e39588eb@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 15/03/2019 00:08, Tom Lane wrote:
> What I'm thinking, therefore, is that 2455ab488 had the right idea but
> didn't take it far enough. We should remove the temp-context logic it
> added to RelationBuildPartitionDesc and instead put that one level up,
> in RelationBuildDesc, where the same temp context can serve all of these
> leak-prone sub-facilities.
>
> Possibly it'd make sense to conditionally compile this so that we only
> do it in a CLOBBER_CACHE_ALWAYS build. I'm not very sure about that,
> but arguably in a normal build the overhead of making and destroying
> a context would outweigh the cost of the leaked memory. The main
> argument I can think of for doing it all the time is that having memory
> allocation work noticeably differently in CCA builds than normal ones
> seems like a recipe for masking normal-mode bugs from the CCA animals.
Having CLOBBER_CACHE_ALWAYS behave differently sounds horrible.
We maintain a free list of AllocSetContexts nowadays, so creating a
short-lived context should be pretty cheap. Or if it's still too
expensive, we could create one short-lived context as a child of
TopMemoryContext, and reuse that on every call, resetting it at the end
of the function.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Matsumura, Ryo | 2019-03-15 07:43:47 | RE: Is PREPARE of ecpglib thread safe? |
Previous Message | MikalaiKeida | 2019-03-15 07:26:59 | RE: Timeout parameters |