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 1t9QIe-00A3xP-Ir for pgsql-bugs@arkaria.postgresql.org; Fri, 08 Nov 2024 14:49:23 +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 1t9QIb-009u4L-O3 for pgsql-bugs@arkaria.postgresql.org; Fri, 08 Nov 2024 14:49:22 +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 1t9QIb-009u3X-FZ for pgsql-bugs@lists.postgresql.org; Fri, 08 Nov 2024 14:49:22 +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 1t9QIT-000rfH-Ii for pgsql-bugs@lists.postgresql.org; Fri, 08 Nov 2024 14:49:21 +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 4A8EnAsp3629174; Fri, 8 Nov 2024 09:49:10 -0500 From: Tom Lane To: Alexander Korotkov cc: Tender Wang , nicolas.maus@bertelsmann.de, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length In-reply-to: References: <18692-72ea398df3ec6712@postgresql.org> <3261639.1730912933@sss.pgh.pa.us> <3534898.1731031548@sss.pgh.pa.us> <3557257.1731042654@sss.pgh.pa.us> Comments: In-reply-to Alexander Korotkov message dated "Fri, 08 Nov 2024 10:47:35 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <3629172.1731077350.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Fri, 08 Nov 2024 09:49:10 -0500 Message-ID: <3629173.1731077350@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Alexander Korotkov writes: > On Fri, Nov 8, 2024 at 7:10 AM Tom Lane wrote: >> WFM. But I'm concerned that you couldn't build a test case >> where the comparison fails. Seems like we need one, in view >> of this bug having escaped detection for so long. > AFAICS, the only use case of CheckIndexCompatible() is ALTER TYPE. In > that case we only serialize and deserialize opclass options without > any involvement of opclass or data type. So, with the current usage > scenario CompareOpclassOptions() is only a paranoid check, but > CheckIndexCompatible() has to do it due to its general semantic. OK. Well, let's settle for having a test case that at least runs the code, even if only the success path is taken. With the release freeze bearing down on us, do you want to wait till after the releases to fix this? It seems non-urgent given how long it took for anyone to notice. regards, tom lane