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 1kz6q6-0006pO-Ft for pgsql-bugs@arkaria.postgresql.org; Mon, 11 Jan 2021 23:43:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kz6q3-0005dL-L4 for pgsql-bugs@arkaria.postgresql.org; Mon, 11 Jan 2021 23:43:07 +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 1kz6q2-0005dE-PO for pgsql-bugs@lists.postgresql.org; Mon, 11 Jan 2021 23:43:07 +0000 Received: from [66.111.4.25] (helo=out1-smtp.messagingengine.com) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kz6pv-0005P0-88 for pgsql-bugs@lists.postgresql.org; Mon, 11 Jan 2021 23:43:06 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id A87665C0178; Mon, 11 Jan 2021 18:42:47 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 11 Jan 2021 18:42:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=eUPPsgmJyuWuJ00+GqxPUveGgXhMSeBOIVXlSRLfQ3Y=; b=iTqlCJtE e+kiyrlzG0iKO+Azyn81A8fFACtUWc7mWdSpj+Ks2lCb10CRtx6RiY9nmVA2UssG omzwo0jTGu3XbDmT7OYta3tEhaHeX0BPTX2LWwPAvaDZhS12P1U2VFCuvBklWrSQ +PnRqttsk0PDg42ATJkzheNBmO+cMY0PqmW04gzD548TkPtfU5dihxmodoL/Kg06 mhNC2zycmCQA6ndMBQ/qX/xKMf/MTHhRdXIJyGs8pLFtBM+AnCtWS2UA+Qijri1M akDPUojEfbb9ybUUTWuJJQUxnOnBrv5lVva2cbxlHuprsGbPX98xAV1c0HK30Sfw JeikV36z1j+ivg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdehvddguddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggugfgjfgesmhekreertderudenucfhrhhomheptehlvhgr rhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh eqnecuggftrfgrthhtvghrnhephfefgeelkefgjeeuhefgfeevleeftedvhefftdeutefg hfekhfduheffkeduteeknecukfhppeduledtrdelhedrudelrddujeejnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhhvghrrhgvsegr lhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: from perhan.alvh.no-ip.org (unknown [190.95.19.177]) by mail.messagingengine.com (Postfix) with ESMTPA id D24DF108005B; Mon, 11 Jan 2021 18:42:46 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 62FF52A0BE3; Mon, 11 Jan 2021 20:42:44 -0300 (-03) Date: Mon, 11 Jan 2021 20:42:44 -0300 From: Alvaro Herrera To: Tomas Vondra Cc: Michael Paquier , Tom Lane , exclusion@gmail.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #16577: Segfault on altering a table located in a dropped tablespace Message-ID: <20210111234244.GA13830@alvherre.pgsql> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20201015151959.GA6823@alvherre.pgsql> User-Agent: Mutt/1.10.1 (2018-07-13) X-Host-Lookup-Failed: Reverse DNS lookup failed for 66.111.4.25 (deferred) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit On 2020-Oct-15, Alvaro Herrera wrote: > It just dawned on me that a way to fix this is to use a pg_shdepend > entry to protect the tablespace from being dropped. Here's a proposed patch for this. -- Álvaro Herrera --UlVJffcvxoiEqYs2 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0001-Prevent-drop-of-tablespace-used-by-partitioned-relat.patch"