On Tue, Jan 28, 2020 at 10:55:11AM +0900, Kohei KaiGai wrote:
>Hello,
>
>I noticed MemoryContextIsValid() called by various kinds of memory context
>routines checks its node-tag as follows:
>
>#define MemoryContextIsValid(context) \
> ((context) != NULL && \
> (IsA((context), AllocSetContext) || \
> IsA((context), SlabContext) || \
> IsA((context), GenerationContext)))
>
>It allows only "known" memory context methods, even though the memory context
>mechanism enables to implement custom memory allocator by extensions.
>Here is a node tag nobody used: T_MemoryContext.
>It looks to me T_MemoryContext is a neutral naming for custom memory context,
>and here is no reason why memory context functions prevents custom methods.
>
Good question. I don't think there's an explicit reason not to allow
extensions to define custom memory contexts, and using T_MemoryContext
seems like a possible solution. It's a bit weird though, because all the
actual contexts are kinda "subclasses" of MemoryContext. So maybe adding
T_CustomMemoryContext would be a better choice, but that only works in
master, of course.
Also, it won't work if we need to add memory contexts to equalfuncs.c
etc. but maybe won't need that - it's more a theoretical issue.
>
>https://github.com/heterodb/pg-strom/blob/master/src/shmbuf.c#L1243
>I recently implemented a custom memory context for shared memory allocation
>with portable pointers. It shall be used for cache of pre-built gpu
>binary code and
>metadata cache of apache arrow files.
>However, the assertion check above requires extension to set a fake node-tag
>to avoid backend crash. Right now, it is harmless to set T_AllocSetContext, but
>feel a bit bad.
>
Interesting. Does that mean the hared memory contexts are part of the
same hierarchy as "normal" contexts? That would be a bit confusing, I
think.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
