Re: BUG #16036: Segmentation fault while doing an update
От | Антон Власов |
---|---|
Тема | Re: BUG #16036: Segmentation fault while doing an update |
Дата | |
Msg-id | 4EA4A542-4C02-4684-B269-FC9254C60028@gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #16036: Segmentation fault while doing an update (Антон Власов <druidvav@gmail.com>) |
Список | pgsql-bugs |
Tried only two concurrent queries and crash is still present, so it’s not about total query count. > 4 окт. 2019 г., в 4:24, Антон Власов <druidvav@gmail.com> написал(а): > > Hello, > > This test script always causes a crash: > > postgres@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, onlyconcurrent ones cause crash. > > >> 4 окт. 2019 г., в 4:20, Andres Freund <andres@anarazel.de> написал(а): >> >> Hi, >> >> On October 3, 2019 6:14:33 PM PDT, "Антон Власов" <druidvav@gmail.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 betterthis 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. >
В списке pgsql-bugs по дате отправления:
Предыдущее
От: Антон ВласовДата:
Сообщение: Re: BUG #16036: Segmentation fault while doing an update