On Tue, Jan 28, 2020 at 2:55 PM Kohei KaiGai <kaigai@heterodb.com> wrote:
> 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.
>
>
> 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.
FWIW the code in https://commitfest.postgresql.org/26/2325/ ran into
exactly the same problem while making nearly exactly the same kind of
thing (namely, a MemoryContext backed by space in the main shm area,
in this case reusing the dsa.c allocator).
