| From: | Антон Власов <druidvav(at)gmail(dot)com> | 
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> | 
| Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org, PG Bug reporting form <noreply(at)postgresql(dot)org> | 
| Subject: | Re: BUG #16036: Segmentation fault while doing an update | 
| Date: | 2019-10-04 01:52:25 | 
| Message-ID: | B48B5066-69BE-4282-A156-22D0188A4B85@gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-bugs | 
At last, i’ve found the source of the problem.
I have a trigger:
create function test_session_bu() returns trigger
    language plpgsql
as
$$
begin
  if new.session_end is not null and old.session_end is null then
    new.is_finished   := true;
    new.success_count := (select count(*) from tracking.test_result where session_id = new.id and status = 'success');
    new.failing_count := (select count(*) from tracking.test_result where session_id = new.id and status = 'failing');
    new.fail_count    := (select count(*) from tracking.test_result where session_id = new.id and status = 'fail');
  end if;
  return new;
end;
$$;
create trigger test_session_bu
    before update
    on tracking.test_session
    for each row
execute procedure tracking.test_session_bu();
Everything works fine without it, when i return it — problem returns too.
As you can see session_end is not affected in the queries. So i tried to modify the trigger to:
create or replace function test_session_bu() returns trigger
    language plpgsql
as
$$
begin
  return new;
end;
$$;
And problem was still in place.
> 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Антон Власов | 2019-10-04 02:11:16 | Re: BUG #16036: Segmentation fault while doing an update | 
| Previous Message | Антон Власов | 2019-10-04 01:45:53 | Re: BUG #16036: Segmentation fault while doing an update |