Michel Pelletier <pelletier.michel@xxxxxxxxx> writes: > This is no doubt the most complex bit of C wrapper I've done for postgres, > and I've run into a bit of a snag. GraphBLAS objects are opaque handles > that have their own new/free functions. After reading mmgr/README I have > registered a callback with CurrentMemoryContext during my aggregator > function that builds values. I suppose what you're doing is returning a pointer to a GraphBLAS object as a Datum (or part of a pass-by-ref Datum)? If so, that's not going to work terribly well, because it ignores the problem that datatype- independent code is going to assume it can copy Datum values using datumCopy() or equivalent logic. More often than not, such copying is done to move the value into a different memory context in preparation for freeing the original context. If you delete the GraphBLAS object when the original context is deleted, you now have a dangling pointer in the copy. We did invent some infrastructure awhile ago that could potentially handle this sort of situation: it's the "expanded datum" stuff. The idea here would be that your representation involving a GraphBLAS pointer would be an efficient-to-operate-on expanded object. You would need to be able to serialize and deserialize that representation into plain self-contained Datums (probably varlena blobs), but hopefully GraphBLAS is capable of going along with that. You'd still need a memory context reset callback attached to each expanded object, to free the associated GraphBLAS object --- but expanded objects are explicitly aware of which context they're in, so at least in principle that should work. (I'm not sure anyone's actually tried to build an expanded-object representation that has external resources, so we might find there are some bugs to fix there.) Take a look at src/include/utils/expandeddatum.h src/backend/utils/adt/expandeddatum.c src/backend/utils/adt/array_expanded.c src/backend/utils/adt/expandedrecord.c regards, tom lane
