Re: BUG #16036: Segmentation fault while doing an update

Hello,

This test script always causes a crash:

postgres(at)gp-app01:~$ cat test.sh
psql -d gdeposylka -c "update tracking.test_session set list_position = list_position + 1 where id = 85638;" &
psql -d gdeposylka -c "update tracking.test_session set list_position = list_position + 1 where id = 85638;" &
psql -d gdeposylka -c "update tracking.test_session set list_position = list_position + 1 where id = 85638;" &
psql -d gdeposylka -c "update tracking.test_session set list_position = list_position + 1 where id = 85638;" &
psql -d gdeposylka -c "update tracking.test_session set list_position = list_position + 1 where id = 85638;" &
psql -d gdeposylka -c "update tracking.test_session set list_position = list_position + 1 where id = 85638;" &
psql -d gdeposylka -c "update tracking.test_session set list_position = list_position + 1 where id = 85638;" &

create table tracking.test_result
(
id serial not null
constraint test_result_pkey
primary key,
session_id integer
constraint test_result_session_id_fkey
references tracking.test_session,
reported_at timestamp(0) default now(),
courier varchar(25) not null,
tracking_number varchar(60) not null,
status varchar(25) not null,
fail_combo integer default 0 not null,
response_test text,
response_real text,
response_time real,
code smallint,
message text,
retry integer
);

create index test_result_session_id_idx
on tracking.test_result (session_id);

Didn’t finish isolating bug from my database so i’m not sure if it work out for you. Single queries work as usual, only concurrent ones cause crash.

> 4 окт. 2019 г., в 4:20, Andres Freund <andres(at)anarazel(dot)de> написал(а):
>
> Hi,
>
> On October 3, 2019 6:14:33 PM PDT, "Антон Власов" <druidvav(at)gmail(dot)com> wrote:
>> Hello,
>>
>> Looks like disabling jit didn’t affect backtrace at all:
>>
>> 0 GetMemoryChunkContext (pointer=0x0) at
>> ./build/../src/include/utils/memutils.h:127
>> #1 pfree (pointer=0x0) at
>> ./build/../src/backend/utils/mmgr/mcxt.c:1033
>> #2 0x0000555d7276aaca in heap_freetuple (htup=<optimized out>) at
>> ./build/../src/backend/access/common/heaptuple.c:1340
>> #3 0x0000555d72918889 in tts_buffer_heap_clear (slot=0x555d73dbb118)
>> at ./build/../src/backend/executor/execTuples.c:652
>> #4 0x0000555d72918cbe in ExecClearTuple (slot=0x555d73dbb118) at
>> ./build/../src/include/executor/tuptable.h:428
>> #5 ExecResetTupleTable (tupleTable=0x555d73db5a10, shouldFree=false)
>
> That's good - I was only looking at that because of the truncated backtrace. Did you do anything to make that work better this time?
>
> Are there any details that you can provide? Schema? Any extensions in use?
>
> Does the problem happen always, or just under concurrency?
>
> Andres
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.