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 1iGCfR-0002MP-Dd for pgsql-bugs@arkaria.postgresql.org; Fri, 04 Oct 2019 01:46:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iGCfQ-0001rG-8i for pgsql-bugs@arkaria.postgresql.org; Fri, 04 Oct 2019 01:46:00 +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 1iGCfP-0001r7-TG for pgsql-bugs@lists.postgresql.org; Fri, 04 Oct 2019 01:46:00 +0000 Received: from mail-lf1-x133.google.com ([2a00:1450:4864:20::133]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iGCfM-0000bl-Lb for pgsql-bugs@lists.postgresql.org; Fri, 04 Oct 2019 01:45:59 +0000 Received: by mail-lf1-x133.google.com with SMTP id u3so3243312lfl.10 for ; Thu, 03 Oct 2019 18:45:56 -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=DicizvJH9+9iBkuYsNEZbX73xT7diUOf2rpXKgwIq+4=; b=njZpji61a7NN3D1ivLF3YDl4GIZXLLuxGnn4sy4zKSCKpdo/xpWJTBm09ftEYarZMV rU1Rh9FetCBwtDkhHVssaTEqgigbhnrLl3m4JdzPx4u7HC/KIW+5J1rmoEudS9hU0IhU 0PvPYipXoKP13g5HGRVt1/+7YtmLeywZgakCCCrDPVcLIuMRg5FqbYJfaZw5gthmNNJX tMUdod/2FTusSZWAs7xwln/6xKQccMSBSYMjZEuVbIxvJlXR1S0G/lacElG8UERg/Srg s9H2Ehq45mL1dkx2ee9Bz8yO2qmxWJwZMTd3ErRdtqUU/+M24Ve25PvdH8US+ANbBFDS Pe3w== 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=DicizvJH9+9iBkuYsNEZbX73xT7diUOf2rpXKgwIq+4=; b=gI6I7M4rj6FZl7JLD6VtlFf7XVdLFupQGwcb/50nWLsy1A5wxBAs3MkIo9MVMCeZJO xM6HN3e+9T+kX9IRGCm+cx8/y4YQU4YFUvFpOCFdur3sr9d4oj2xU94HmJ0wnBYhwE26 Q2dM9Jui86v/8K+7P/eUNleeyFg24b0v2VVEKdQ9jh+ssE7VRvv+5F9WRqcWgZkNO2UO uzn4ZF0pEqed4oTxhWzyJVXcF8O7CnFdH4HoWPeg/ca9aiFeZ2oAewbmkYWP3dReVofQ ZwHRfJCSA6nhLjFvzra6yzEizGSwOFyQuADWueWi9g2zOKNv+JuE9TvpI1escMW5vTi6 HKuw== X-Gm-Message-State: APjAAAUpQC/DBhmQYEPum7SYWdMuW8iG5ROKi7Up5tV64vvtf8TebiON f9DSSkb1NVi7vnUiVa/W/Rw= X-Google-Smtp-Source: APXvYqw6XWjWHrxI8NKDG0M2OHJEDGPwkWracgD4wvPcv6pkUf8olGRPjriJ2vyxUWdWF+zRRj7Kzw== X-Received: by 2002:a19:f707:: with SMTP id z7mr7581350lfe.142.1570153554966; Thu, 03 Oct 2019 18:45:54 -0700 (PDT) Received: from [127.0.0.1] (router.dv-dev.ru. [188.235.1.38]) by smtp.gmail.com with ESMTPSA id e29sm888591ljb.105.2019.10.03.18.45.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Oct 2019 18:45:54 -0700 (PDT) From: =?utf-8?B?0JDQvdGC0L7QvSDQktC70LDRgdC+0LI=?= Message-Id: <4E62ED10-FD03-4954-90DD-6056857F0ACA@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E55FDF04-4BEE-41E0-A34C-6E1187D85B58" 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:45:53 +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=_E55FDF04-4BEE-41E0-A34C-6E1187D85B58 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Tried with default debian configuration - problem persists. I=E2=80=99ve = got full backtrace when reduced shared_buffers from 18G to 1G. Tried to = simulate the problem in artificial environment, but cannot repeat it. On real data it is 100% repeatable. > 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=_E55FDF04-4BEE-41E0-A34C-6E1187D85B58 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Tried= with default debian configuration - problem persists. I=E2=80=99ve got = full backtrace when reduced shared_buffers from 18G to 1G. Tried to = simulate the problem in artificial environment, but cannot repeat = it.
On real data it is 100% repeatable.

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=_E55FDF04-4BEE-41E0-A34C-6E1187D85B58--