Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iGClj-0002Wc-PX for pgsql-bugs@arkaria.postgresql.org; Fri, 04 Oct 2019 01:52:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iGCli-0003ST-GE for pgsql-bugs@arkaria.postgresql.org; Fri, 04 Oct 2019 01:52:30 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iGCli-0003SM-4M for pgsql-bugs@lists.postgresql.org; Fri, 04 Oct 2019 01:52:30 +0000 Received: from mail-lj1-x244.google.com ([2a00:1450:4864:20::244]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iGClf-0000en-TG for pgsql-bugs@lists.postgresql.org; Fri, 04 Oct 2019 01:52:29 +0000 Received: by mail-lj1-x244.google.com with SMTP id m13so4773553ljj.11 for ; Thu, 03 Oct 2019 18:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=TR8bb+s1+pl7Vz98HSCGz8DBXBIrMTYCCLg7zqC79Wo=; b=BkcLY16IlA8TaTi1mQKDRCtw0oIvzU6I0NWVecM6HAVXabbOA5Ly6oRHImjcNfdvAY ec2LwcSSLMgBn5KXKN+02vQJRGkEuK1L8e1MFvsL5CL9GP+eVPvOQrkuBMDYeP2uUIWR W9b/nALGWQX1fV59ztXOisOM4PVfL4E0nMt0bR5M8JvdJA9KHTIPDi68zyljQTgopCj0 8Ay9aJyuG86iVjuuRNTIVqqDd5fOrePZCarbP1SGhyf/ow6wjrqBBXNP1Ml8UXs1PLn+ fHL6xaUFmEFLr54c1c/QsESoiN5NbdjfwC4mjhcPxv0WJAavw3JseP4KjFhxBk4m5EN3 zmnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=TR8bb+s1+pl7Vz98HSCGz8DBXBIrMTYCCLg7zqC79Wo=; b=F7ymL0MznNwpjqAvezI/44hcqejPMwIHW01u0Pzede91NNixcl02w8pu73bMpElHGN /sLWBIK/7lHEWV8XqEQSA3cjnjBh+EJV6yPsShF+wDOjNbxa4c+bNFDyYz2kE/DDaTLo 67FFgrIgKIsELLFhJlSRCpRDfZ6nFffZ78h4vzvyi+SSHdf7x10QJxcLnw8uwdvLs1+N wd0gNUXUwafadPMLrd6Z6RhrH3dWh+eGV6G01IjrLGHsq3QeI4Gunhl9WzlJrTFwko3h zA1lQSVLhij0ARVJyq6q1rnMxKAyvw+UwfGxLOE5x+Yb3Y6w4z3qygYePp85l/qM7WdR vvgw== X-Gm-Message-State: APjAAAWhdLtdKkmSu5sHBCyqI/W2gEbLegZEtRWsffXCUOrwrhg02OEy MwKvPgQU11QaxtSV0w05Z18= X-Google-Smtp-Source: APXvYqx5LsxFdepQRnhT9lDcSuWx67dz0+SLpI4OQqllV32RX9pc9hBCVttq4Ita+p1SnXaCdjxgPw== X-Received: by 2002:a2e:8184:: with SMTP id e4mr8146169ljg.240.1570153946868; Thu, 03 Oct 2019 18:52:26 -0700 (PDT) Received: from [127.0.0.1] (router.dv-dev.ru. [188.235.1.38]) by smtp.gmail.com with ESMTPSA id y3sm816949lfh.97.2019.10.03.18.52.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Oct 2019 18:52:26 -0700 (PDT) From: =?utf-8?B?0JDQvdGC0L7QvSDQktC70LDRgdC+0LI=?= Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A492DA18-85FD-484B-8F21-FBDC97C9B999" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: BUG #16036: Segmentation fault while doing an update Date: Fri, 4 Oct 2019 04:52:25 +0300 In-Reply-To: Cc: pgsql-bugs@lists.postgresql.org, PG Bug reporting form To: Andres Freund References: <16036-28184c90d952fb7f@postgresql.org> <4E1FB33C-7280-487B-B3D1-D3C247AA9E3D@anarazel.de> X-Mailer: Apple Mail (2.3445.104.11) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --Apple-Mail=_A492DA18-85FD-484B-8F21-FBDC97C9B999 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 At last, i=E2=80=99ve 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 :=3D true; new.success_count :=3D (select count(*) from tracking.test_result = where session_id =3D new.id and status =3D 'success'); new.failing_count :=3D (select count(*) from tracking.test_result = where session_id =3D new.id and status =3D 'failing'); new.fail_count :=3D (select count(*) from tracking.test_result = where session_id =3D new.id and status =3D '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 =E2=80=94 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 =D0=BE=D0=BA=D1=82. 2019 =D0=B3., =D0=B2 4:20, Andres Freund = =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0): >=20 > Hi,=20 >=20 > On October 3, 2019 6:14:33 PM PDT, "=D0=90=D0=BD=D1=82=D0=BE=D0=BD = =D0=92=D0=BB=D0=B0=D1=81=D0=BE=D0=B2" wrote: >> Hello, >>=20 >> Looks like disabling jit didn=E2=80=99t affect backtrace at all: >>=20 >> 0 GetMemoryChunkContext (pointer=3D0x0) at >> ./build/../src/include/utils/memutils.h:127 >> #1 pfree (pointer=3D0x0) at >> ./build/../src/backend/utils/mmgr/mcxt.c:1033 >> #2 0x0000555d7276aaca in heap_freetuple (htup=3D) at >> ./build/../src/backend/access/common/heaptuple.c:1340 >> #3 0x0000555d72918889 in tts_buffer_heap_clear (slot=3D0x555d73dbb118)= >> at ./build/../src/backend/executor/execTuples.c:652 >> #4 0x0000555d72918cbe in ExecClearTuple (slot=3D0x555d73dbb118) at >> ./build/../src/include/executor/tuptable.h:428 >> #5 ExecResetTupleTable (tupleTable=3D0x555d73db5a10, = shouldFree=3Dfalse) >=20 > 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? >=20 > Are there any details that you can provide? Schema? Any extensions in = use?=20 >=20 > Does the problem happen always, or just under concurrency? >=20 > Andres > --=20 > Sent from my Android device with K-9 Mail. Please excuse my brevity. --Apple-Mail=_A492DA18-85FD-484B-8F21-FBDC97C9B999 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 At = last, i=E2=80=99ve 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  =
 :=3D true;
    =
new.success_count =
:=3D (select count(*) from tracking.test_result =
where session_id =3D new.id and status =3D 'success');
    new.failing_count :=3D (select count(*) from tracking.test_result =
where session_id =3D new.id and status =3D 'failing');
    new.fail_count    :=3D (select count(*) from tracking.test_result =
where session_id =3D new.id and status =3D '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 =E2=80=94 = 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 =D0=BE=D0=BA=D1=82. 2019 =D0=B3., =D0=B2 = 4:20, Andres Freund <andres@anarazel.de> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0= =D0=BB(=D0=B0):

Hi, 

On October 3, 2019 6:14:33 PM PDT, "=D0=90=D0=BD=D1=82=D0=BE=D0= =BD =D0=92=D0=BB=D0=B0=D1=81=D0=BE=D0=B2" <druidvav@gmail.com> = wrote:
Hello,

Looks like disabling jit = didn=E2=80=99t affect backtrace at all:

0 =  GetMemoryChunkContext (pointer=3D0x0) at
./build/../src/include/utils/memutils.h:127
#1 =  pfree (pointer=3D0x0) at
./build/../src/backend/utils/mmgr/mcxt.c:1033
#2 =  0x0000555d7276aaca in heap_freetuple (htup=3D<optimized = out>) at
./build/../src/backend/access/common/heaptuple.c:1340
#3  0x0000555d72918889 in tts_buffer_heap_clear = (slot=3D0x555d73dbb118)
at = ./build/../src/backend/executor/execTuples.c:652
#4 =  0x0000555d72918cbe in ExecClearTuple (slot=3D0x555d73dbb118) at
./build/../src/include/executor/tuptable.h:428
#5=  ExecResetTupleTable (tupleTable=3D0x555d73db5a10, = shouldFree=3Dfalse)

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.

= --Apple-Mail=_A492DA18-85FD-484B-8F21-FBDC97C9B999--