Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gK9it-0002Fi-Oc for pgsql-general@arkaria.postgresql.org; Tue, 06 Nov 2018 22:21:23 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gK9ir-000441-Kf for pgsql-general@arkaria.postgresql.org; Tue, 06 Nov 2018 22:21:21 +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_SHA384:256) (Exim 4.89) (envelope-from ) id 1gK9iq-0003sa-HG; Tue, 06 Nov 2018 22:21:21 +0000 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gK9io-0002oB-0W; Tue, 06 Nov 2018 22:21:20 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 89471EF3; Tue, 6 Nov 2018 17:21:15 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 06 Nov 2018 17:21:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=z9c9sDfoFTIuOdSdZAqbUJ3FufV zmbrA3SAmr017+LA=; b=p1r4ZGUHKJJzhcty69nwMjlESQPSttG4Sfk+/INmVLe ITX60d1XytljjwKIFzDH48ksGjHbYYV1FZWdZOWCKcMqk6bR3UStwbtImV+WAppc h/PEP56KQ16eqarpefGQRm5MxcXZ12Cxhm12OVZYNUk9DJ8PxLGsIfb53T37Q5MY BTdEAr84YDqE1l4ixKZu2MRGUq9p8mCsiuXfzHVYw2ELbpazEdRkmhLQ8XPWfdFB k6nxONeVZVuzsHgNZS2lVcTwmUPO30ezfgS04HlCSZy0qU3SGTqjjZxG+DaDFZrP HVQwO9iHZu/PGvm20wpI2kzt2aBRThHdrKzz6/ccjBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=z9c9sD foFTIuOdSdZAqbUJ3FufVzmbrA3SAmr017+LA=; b=f+AsE5N4VS1TOhqePfdqRk mSWHIPPwVoYDVNERcePqSK8+1VSVZ1pzTldMYmfvnx6KvqHkEfT1GvOxudRtN5SM KVWxaRgzARLZ+6X+m8TUTTOv5vMFxGeYaIgPZ3VODDa4knzDDV9H+rFW0gKOeRuh Py1qewGyfFK++VeOEda7anteT+gLQYYdocrPrfWZnOH+zPPcy8At/+VyfeFy0ENE Dr+YH5LabWel7CGmGWaLzXn43GJZWG2eHDZDu7IUX00ccxvAkTJQAuQQSn7jdPfj 9Yz+s2P0tnzwBs5ATk6tlDq98eZc1bNtxKuoIgyEZRlzIc2dNEBniqGmibwM68bQ == X-ME-Sender: X-ME-Proxy: Received: from intern.anarazel.de (c-98-210-140-171.hsd1.ca.comcast.net [98.210.140.171]) by mail.messagingengine.com (Postfix) with ESMTPA id 4B888102ED; Tue, 6 Nov 2018 17:21:14 -0500 (EST) Date: Tue, 6 Nov 2018 14:21:13 -0800 From: Andres Freund To: Tom Lane Cc: =?utf-8?Q?Ond=C5=99ej?= Bouda , Alvaro Herrera , pgsql-hackers@lists.postgresql.org, pgsql-general@lists.postgresql.org Subject: Re: backend crash on DELETE, reproducible locally Message-ID: <20181106222113.lcxpuuo2ht2rtw2n@alap3.anarazel.de> References: <20181106194553.dynhd2xuivo56ymd@alvherre.pgsql> <33d144b9-5208-8d32-7e95-94ed4d2931b8@email.cz> <450.1541535425@sss.pgh.pa.us> <134c09b5-3eb0-bafd-2aeb-f383e1e21b8a@email.cz> <2432.1541538215@sss.pgh.pa.us> <2877.1541538838@sss.pgh.pa.us> <4375.1541540840@sss.pgh.pa.us> <20181106215457.h36ccb5wywatcqhz@alap3.anarazel.de> <5323.1541542300@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5323.1541542300@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, On 2018-11-06 17:11:40 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2018-11-06 16:47:20 -0500, Tom Lane wrote: > >> Looks like somebody forgot to list > >> RELOPT_KIND_GIST in RELOPT_KIND_INDEX, but is that the > >> fault of commit c203d6cf8 or was it busted before? > > > Looks new: > > + RELOPT_KIND_INDEX = RELOPT_KIND_BTREE|RELOPT_KIND_HASH|RELOPT_KIND_GIN|RELOPT_KIND_SPGIST, > > there aren't any other "for all indexes" type options, so the whole > > category didn't exist before. > > > It also strikes me as a really bad idea, even if RELOPT_KIND_GIST > > wouldn't have been omitted: It breaks index am extensibility. > > Hm, well, that enum already knows about all index types, doesn't it? Not quite sure what you mean. Before c203d6cf8 there weren't reloptions across index types. But after it, if one adds a new index AM via an extension, one can't set recheck_on_update = false for indexes using it, even though the feature affects such indexes. We support adding indexes AMs at runtime these days, including WAL logging (even though that's a bit voluminous). There's even a contrib index AM... The list of AMs is supposed to be extensible at runtime, cf add_reloption_kind(). Greetings, Andres Freund