Re: Segmentation fault when calling BlessTupleDesc in a C function in parallel on PostgreSQL-(12.6, 12.7, 13.2, 13.3)

Eric Thinnes <e.thinnes@gmx.de> writes:
> The function always delivers the same result with the same call
> parameters except for the determination of the result types and the
> generation of the TupleDesc, the function has no side effects.

BlessTupleDesc certainly has side effects; that's pretty much the
whole point of it.  If you're marking this thing as parallel safe,
I imagine that the problem boils down to "parallel worker locally
registers a blessed tupdesc, but the leader has never heard of it,
so fails to interpret the returned tuple".

Perhaps a workaround is possible by using a named composite type
instead of generating a rowtype on the fly?  But that won't work
if you want this to be polymorphic.

Also, I recall that there are provisions in typcache.c in recent
versions to support a shared pool of registered (i.e. blessed)
tuple descriptors.  That would likely solve your problem, but
I've never looked into how to use that code.  I doubt just
calling BlessTupleDesc is enough.  In particular, I imagine
you need to make sure the leader process creates the tupdesc
first, so it's available to all workers.

            regards, tom lane