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(dot)thinnes(at)gmx(dot)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