From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michel Pelletier <pelletier(dot)michel(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Question about MemoryContextRegisterResetCallback |
Date: | 2019-01-13 17:30:42 |
Message-ID: | 9801.1547400642@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Michel Pelletier <pelletier(dot)michel(at)gmail(dot)com> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Michel Pelletier | 2019-01-13 18:51:45 | Re: Question about MemoryContextRegisterResetCallback |
Previous Message | Michel Pelletier | 2019-01-13 17:00:55 | Question about MemoryContextRegisterResetCallback |