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

Because of the parallelism it is difficult to debug the error.
I have less experience with that.

But I have now rewritten the function setof_kpos a little and
no longer use the user-specific result type. The c-function
was of course adjusted accordingly and the result type was not
more dynamically determined via the corresponding functions.

CREATE OR REPLACE FUNCTION setof_kpos(
     kontopositionen text
   , OUT Pos         smallint
   , OUT Count       smallint
   , OUT Konto       integer
   , OUT Sign        smallint
   , OUT BTyp        smallint
   , OUT Betrag      bigint
   )
   RETURNS SETOF RECORD
   AS '/var/lib/postgresql/lib/13/test', 'set_of_kpos'
   LANGUAGE C IMMUTABLE STRICT
   PARALLEL SAFE
;

That seems to solve the problem.

 > 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".

I noticed that as well. Whenever it was the leader's turn the crash came.
That explains a lot and I now understand why the changes brought success.


But it doesn't matter, it does and I am richer by one experience.

Thank you very much for the good and quick help.

Eric Thinnes


Am 14.05.21 um 17:20 schrieb Tom Lane:
> 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
>