Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oePoT-0006Se-Oy for pgsql-committers@arkaria.postgresql.org; Fri, 30 Sep 2022 23:53:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oePoS-0000uj-8M for pgsql-committers@arkaria.postgresql.org; Fri, 30 Sep 2022 23:53:00 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oePoS-0000uV-0v for pgsql-committers@lists.postgresql.org; Fri, 30 Sep 2022 23:53:00 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oePoL-0004mo-Df for pgsql-committers@lists.postgresql.org; Fri, 30 Sep 2022 23:52:59 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 28UNqiY8841353; Fri, 30 Sep 2022 19:52:48 -0400 From: Tom Lane To: Peter Geoghegan cc: Jaime Casanova , pgsql-committers@lists.postgresql.org Subject: Re: pgsql: Avoid improbable PANIC during heap_update. In-reply-to: References: <692791.1664573331@sss.pgh.pa.us> <741997.1664574971@sss.pgh.pa.us> Comments: In-reply-to Peter Geoghegan message dated "Fri, 30 Sep 2022 15:03:46 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <841351.1664581964.1@sss.pgh.pa.us> Date: Fri, 30 Sep 2022 19:52:44 -0400 Message-ID: <841352.1664581964@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Peter Geoghegan writes: > On Fri, Sep 30, 2022 at 2:56 PM Tom Lane wrote: >> Could be, because we haven't seen field reports of this in v14 yet. > I would be more confident here were it not for the recent > heap_delete() issue reported by one of my AWS colleagues (and fixed by > another, Jeff Davis). See commit 163b0993 if you missed it before now. Hmm, okay, though that's really a distinct bug of the same ilk. You're right that I'd not paid close attention to that thread after Jeff diagnosed the problem. It does seem like Robins' report shows that there's some way that v13 will set the AV bit without a cleanup lock ... does that constitute a bug in itself? regards, tom lane