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(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
>