Re: BUG #16036: Segmentation fault while doing an update
От | Антон Власов |
---|---|
Тема | Re: BUG #16036: Segmentation fault while doing an update |
Дата | |
Msg-id | C2DA3A10-8D6F-4EC0-9A24-58F5480FCF85@gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #16036: Segmentation fault while doing an update (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: BUG #16036: Segmentation fault while doing an update
(Антон Власов <druidvav@gmail.com>)
|
Список | pgsql-bugs |
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, only concurrentones 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 по дате отправления:
Предыдущее
От: Andres FreundДата:
Сообщение: Re: BUG #16036: Segmentation fault while doing an update
Следующее
От: Антон ВласовДата:
Сообщение: Re: BUG #16036: Segmentation fault while doing an update