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 1iGD41-00030Z-UA for pgsql-bugs@arkaria.postgresql.org; Fri, 04 Oct 2019 02:11:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iGD3z-0006Gb-CB for pgsql-bugs@arkaria.postgresql.org; Fri, 04 Oct 2019 02:11:23 +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 1iGD3z-0006GI-10 for pgsql-bugs@lists.postgresql.org; Fri, 04 Oct 2019 02:11:23 +0000 Received: from mail-lf1-x142.google.com ([2a00:1450:4864:20::142]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iGD3v-0000uG-Qr for pgsql-bugs@lists.postgresql.org; Fri, 04 Oct 2019 02:11:22 +0000 Received: by mail-lf1-x142.google.com with SMTP id u3so3275867lfl.10 for ; Thu, 03 Oct 2019 19:11:18 -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=3J0GvSf+0EW4+wdlIfifi1yCDM9lTaYmEm5W3cYbvL8=; b=QF0BUS5caekakNcQkP3Ydk/YXJI1K1ztUezAIT4eTyIBui6TWJLRqCGSbi0OPLkvMg qsv8CbHO/kiRwVLVeVCGR7FQZ6z3qYzu2HZiWHBps778N9tGRlXm8Ln3K206Yu1+s3sO V3s9nF9RoDQHjo6SO9RrEVH94HEa2gyNnBeQjR3/tCBumOHYrkBnLHhZRGZwvubcZb7x JujGFcoziyu22DChX96o19bbmKwasWk+OHzyfcdx1hWHpGU2nd2x2iwMO0XtmmZSqUz1 jSfPVVZh7jPLwrOxnWNLL7iff6B5XP2HqAovrGgz6+dMdbLDEscSlZTpY0UlrGZdnKJJ 9rKA== 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=3J0GvSf+0EW4+wdlIfifi1yCDM9lTaYmEm5W3cYbvL8=; b=F98InFuLosePuckgxCDZYCGk2vGdE8mFEsuPp6XmsPXzA+RlLXseScl3K7wiahs3/0 sfevTTiw7lrJMOw3ueqel/yAYAtlQeWQubQRk5YV1Qb5zh86gvCKucz4THD6DlXZm8SC VCnc2t9NNwJBnznV/vgov1lOUkzgQzwyQoP0ObA4eZTp+hEYtRn1bndiF9tAm2/bnAla JgfBQZ5nsZuuhzyYb+RrrJYZfQzEZvJc0WWP4BwNF7XJ9vj8cllq6ZSpbs0T/QfKBMAO K5xr8NTfmDul7ydNjuWupYgh4HQMXXiZsMHaMsoVhd4elJVe5pAce7yUJHer/YiLE52D sA2w== X-Gm-Message-State: APjAAAW9gL9IfN5WztqF8i+kF0MIDURZovWJZcSpMvyDAhaY7JYB4ZCf foTo3ZOC/r7Nk1XpmquoyCs= X-Google-Smtp-Source: APXvYqxuY9k39XCtlqJhhCeQmHFvYM6BQsvvlS8yo854UWdHXW0cRSfuyVZpSHAiM/m61d1WUSyfDA== X-Received: by 2002:ac2:59c2:: with SMTP id x2mr6741633lfn.125.1570155078167; Thu, 03 Oct 2019 19:11:18 -0700 (PDT) Received: from [127.0.0.1] (router.dv-dev.ru. [188.235.1.38]) by smtp.gmail.com with ESMTPSA id a23sm797780lfl.66.2019.10.03.19.11.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Oct 2019 19:11:17 -0700 (PDT) From: =?utf-8?B?0JDQvdGC0L7QvSDQktC70LDRgdC+0LI=?= Message-Id: <746398E3-F4E1-4F14-A686-3394F27011DC@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BB889E69-3FF4-4092-A195-E17E0AD59712" 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 05:11:16 +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=_BB889E69-3FF4-4092-A195-E17E0AD59712 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello! Reproducible schema: create table test_table ( id serial, field int default 0 not null ); create or replace function test_table_bu() returns trigger language plpgsql as $$ begin return new; end; $$; create trigger test_table_bu before update on test_table for each row execute procedure test_table_bu(); insert into test_table (field) values (0); test.sh: psql -d gdeposylka -c "update test_table set field =3D field + 1 where = id =3D 1;" & psql -d gdeposylka -c "update test_table set field =3D field + 1 where = id =3D 1;" & > 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=_BB889E69-3FF4-4092-A195-E17E0AD59712 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hello!

Reproducible = schema:

create table test_table (
    id serial, field int default 0 not null
);

create or replace function =
test_table_bu() returns trigger
    language plpgsql
as
$$
begin
  return =
new;
end;
$$;

create =
trigger test_table_bu
    before update
    on =
test_table
    for each row
execute procedure test_table_bu();

insert into test_table (field) values =
(0);
test.sh:

psql -d gdeposylka -c "update test_table set = field =3D field + 1 where id =3D 1;" &
psql -d = gdeposylka -c "update test_table set field =3D field + 1 where id =3D = 1;" &

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=_BB889E69-3FF4-4092-A195-E17E0AD59712--