Subject: Re: Segmentation fault when calling BlessTupleDesc in a C function in
 parallel on PostgreSQL-(12.6, 12.7, 13.2, 13.3)
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
References: <99aaa2eb-e194-bf07-c29a-1a76b4f2bcf9@gmx.de>
 <CALj2ACV+SiO=xr0A3n13kRKVAgUjChu=4TxFKi8WOX4xxUvk3A@mail.gmail.com>
From: Eric Thinnes <e.thinnes@gmx.de>
Message-ID: <105daf69-a864-2e83-1f93-a85e4ba80510@gmx.de>
Date: Fri, 14 May 2021 14:26:52 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: 
 <CALj2ACV+SiO=xr0A3n13kRKVAgUjChu=4TxFKi8WOX4xxUvk3A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: de-DE
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/105daf69-a864-2e83-1f93-a85e4ba80510%40gmx.de>
Precedence: bulk


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.thinnes@gmx.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@test=3D# SET max_parallel_workers_per_gather TO 4;
>> SET
>> Zeit: 0,558 ms
>> postgres:5433:et@test=3D#* 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 pro=
cess
>> 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: Fehlgeschlag=
en.
>> 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@test=3D#* 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@test=3D#* 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
>