On Tue, Jan 28, 2020 at 2:55 PM Kohei KaiGai <kai...@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).
