Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qvJlf-004ToL-Lu for pgsql-bugs@arkaria.postgresql.org; Tue, 24 Oct 2023 15:56:31 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qvJlc-009ERW-KP for pgsql-bugs@arkaria.postgresql.org; Tue, 24 Oct 2023 15:56:29 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qvJlc-009ERO-BE for pgsql-bugs@lists.postgresql.org; Tue, 24 Oct 2023 15:56:29 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qvJlV-002UBF-I6 for pgsql-bugs@lists.postgresql.org; Tue, 24 Oct 2023 15:56:28 +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 39OFuHRe572495; Tue, 24 Oct 2023 11:56:17 -0400 From: Tom Lane To: Hans Buschmann cc: Amit Langote , Peter Geoghegan , "David G. Johnston" , "pgsql-bugs@lists.postgresql.org" Subject: Re: AW: AW: AW: BUG #18147: ERROR: invalid perminfoindex 0 in RTE with relid xxxxx In-reply-to: References: <18147-6fc796538913ee88@postgresql.org> ,<2796464.1696525626@sss.pgh.pa.us> <9fdfed847859435e8641e613198be9e3@nidsa.net>,<3319880.1696778678@sss.pgh.pa.us> <3c9fe737f6aa4ae9b0dc19bffd97e106@nidsa.net>,<408285.1698085850@sss.pgh.pa.us> Comments: In-reply-to Hans Buschmann message dated "Tue, 24 Oct 2023 06:16:13 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <572493.1698162977.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Oct 2023 11:56:17 -0400 Message-ID: <572494.1698162977@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hans Buschmann writes: > 1st query: ERROR > 2nd query to or_followup_archiv: Succeeds > then 1st query repeated: SUCCEEDS!! > With this direct update to or_followup_archiv (or an unclustered table) = the error disappears. Yeah. After more study I think there's less there than meets the eye. If the row update manages to be HOT then we don't need to make any new index entries so we never reach the troublesome code. In your original reproducer, the CLUSTER step was important because it left the target tuple in a fully-packed page with no room for a HOT update on the same page. When playing around with variants or even re-executing the same query, it matters how much free space there is on the page containing the target tuple, and that is affected by all sorts of seemingly-irrelevant actions. Anyway, we do now have a simple and reliable reproducer, so we can work on fixing this. Thanks again for the report! regards, tom lane