From: Антон Власов <druidvav@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-bugs@lists.postgresql.org, PG Bug reporting form <noreply@postgresql.org>
Subject: Re: BUG #16036: Segmentation fault while doing an update
Date: Fri, 4 Oct 2019 04:52:25 +0300
Message-ID: <B48B5066-69BE-4282-A156-22D0188A4B85@gmail.com> (raw)
In-Reply-To: <A1695349-530C-4871-AED5-0262A9BC9920@anarazel.de>
References: <16036-28184c90d952fb7f@postgresql.org>
<4E1FB33C-7280-487B-B3D1-D3C247AA9E3D@anarazel.de>
<FBA5344D-9356-49BA-9B47-C3705C2E9481@gmail.com>
<A1695349-530C-4871-AED5-0262A9BC9920@anarazel.de>
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@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 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.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: druidvav@gmail.com, andres@anarazel.de, noreply@postgresql.org
Subject: Re: BUG #16036: Segmentation fault while doing an update
In-Reply-To: <B48B5066-69BE-4282-A156-22D0188A4B85@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox