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

From: Eric Thinnes <e(dot)thinnes(at)gmx(dot)de>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: Segmentation fault when calling BlessTupleDesc in a C function in parallel on PostgreSQL-(12.6, 12.7, 13.2, 13.3)
Date: 2021-05-14 12:26:52
Message-ID: 105daf69-a864-2e83-1f93-a85e4ba80510@gmx.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs


I do think it should be possible.

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.

If BlessTupleDesc inevitably leads to side effects, I am happy to be
instructed to improve something.
So far I haven't found any information on this.

Am 14.05.21 um 13:45 schrieb Bharath Rupireddy:
> On Fri, May 14, 2021 at 4:49 PM Eric Thinnes <e(dot)thinnes(at)gmx(dot)de> wrote:
>>
>>
>> Hello Postgres team,
>>
>> i get a segmentation fault when calling BlessTupleDesc in a C function
>> in parallel.
>>
>> System Configuration
>> ---------------------
>> Architecture : Intel Pentium
>> Operating System : Ubuntu versions: 16.04.7 LTS, 18.04.5 LTS,
>> 20.04.2 LTS
>> PostgreSQL version : PostgreSQL-(12.6, 12.7, 13.2, 13.3)
>> Compiler used : gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
>>
>> Please enter a FULL description of your problem:
>> ------------------------------------------------
>>
>> In the version with the configure option --enable-cassert, the process
>> is aborted
>> before the segmentation fault occurs.
>>
>> It is possible that the error does not occur the first time and that
>> the call has to be repeated several times.
>> That probably indicates a timing problem with concurrency.
>>
>>
>> postgres:5433:et(at)test=# SET max_parallel_workers_per_gather TO 4;
>> SET
>> Zeit: 0,558 ms
>> postgres:5433:et(at)test=#* SELECT sum(sign*Betrag) FROM kpos_test,
>> setof_kpos(kpos);
>> INFO: pid: 9132, outTypeId: 40962
>> INFO: outTypRelId: 40960, typlen: -1, typbyval: 0, typalign: d
>> INFO: pid: 9131, outTypeId: 40962
>> INFO: outTypRelId: 40960, typlen: -1, typbyval: 0, typalign: d
>> INFO: pid: 9130, outTypeId: 40962
>> INFO: outTypRelId: 40960, typlen: -1, typbyval: 0, typalign: d
>> INFO: pid: 9134, outTypeId: 40962
>> INFO: outTypRelId: 40960, typlen: -1, typbyval: 0, typalign: d
>> INFO: pid: 9133, outTypeId: 40962
>> INFO: outTypRelId: 40960, typlen: -1, typbyval: 0, typalign: d
>> WARNING: terminating connection because of crash of another server process
>> DETAIL: The postmaster has commanded this server process to roll back
>> the current transaction and exit, because another server process exited
>> abnormally and possibly corrupted shared memory.
>> TIP: In a moment you should be able to reconnect to the database and
>> repeat your command.
>> SSL-SYSCALL-Fehler: Dateiende entdeckt
>> Die Verbindung zum Server wurde verloren. Versuche Reset: Fehlgeschlagen.
>> Zeit: 421,098 ms
>> ::@!>? \q
>>
>> If I call the c function once with an empty argument before the
>> parallel scan, the error does not occur.
>>
>>
>> SET max_parallel_workers_per_gather TO 4;
>> SET
>> Zeit: 0,390 ms
>> postgres:5433:et(at)test=#* SELECT setof_kpos('');
>> INFO: pid: 12396, outTypeId: 40962
>> INFO: outTypRelId: 40960, typlen: -1, typbyval: 0, typalign: d
>> setof_kpos
>> ------------
>> (0 Zeilen)
>>
>> Zeit: 1,253 ms
>> postgres:5433:et(at)test=#* SELECT sum(sign*Betrag) FROM kpos_test,
>> setof_kpos(kpos);
>> INFO: pid: 12400, outTypeId: 40962
>> INFO: outTypRelId: 40960, typlen: -1, typbyval: 0, typalign: d
>> INFO: pid: 12398, outTypeId: 40962
>> INFO: outTypRelId: 40960, typlen: -1, typbyval: 0, typalign: d
>> INFO: pid: 12399, outTypeId: 40962
>> INFO: outTypRelId: 40960, typlen: -1, typbyval: 0, typalign: d
>> INFO: pid: 12397, outTypeId: 40962
>> INFO: outTypRelId: 40960, typlen: -1, typbyval: 0, typalign: d
>> sum
>> -----
>> 0
>> (1 Zeile)
>>
>> I don't know how to fix this.
>
> I'm not sure if this makes sense - do you want to set the set_of_kpos
> function's parallel safety to 'unsafe' or 'restricted'?
>
> With Regards,
> Bharath Rupireddy.
> EnterpriseDB: http://www.enterprisedb.com
>

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message KES 2021-05-14 12:39:31 Re: BUG #16968: Planner does not recognize optimization
Previous Message Bharath Rupireddy 2021-05-14 12:10:33 Re: Query on postgres_fdw extension