Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gkGy4-0005Yn-LQ for pgsql-hackers@arkaria.postgresql.org; Thu, 17 Jan 2019 23:21:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gkGy3-00010b-Ao for pgsql-hackers@arkaria.postgresql.org; Thu, 17 Jan 2019 23:20:59 +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_SHA1:256) (Exim 4.89) (envelope-from ) id 1gkGy3-00010U-3s for pgsql-hackers@lists.postgresql.org; Thu, 17 Jan 2019 23:20:59 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gkGy1-0004Td-6O for pgsql-hackers@postgresql.org; Thu, 17 Jan 2019 23:20:58 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x0HNKplY019221; Thu, 17 Jan 2019 18:20:51 -0500 From: Tom Lane To: Alvaro Herrera cc: Peter Geoghegan , PostgreSQL Hackers Subject: Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages) In-reply-to: <201901172247.uqvtve6ekpvh@alvherre.pgsql> References: <201901172247.uqvtve6ekpvh@alvherre.pgsql> Comments: In-reply-to Alvaro Herrera message dated "Thu, 17 Jan 2019 19:47:23 -0300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19219.1547767251.1@sss.pgh.pa.us> Date: Thu, 17 Jan 2019 18:20:51 -0500 Message-ID: <19220.1547767251@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Alvaro Herrera writes: > On 2019-Jan-17, Tom Lane wrote: >> Hm. Still, I can't believe that it's appropriate for a partitioned index >> to have exactly the same kind of dependency on the master index as it >> does on the associated table. > So there are three necessary features: > * The partition can be dropped, which takes down the index partition > * The master index can be dropped, which takes down the index partition > * The index partition must never be allowed to be dropped on its own. > There is a symmetry to these that led me to have the same kind of > dependency from the index partition to the other two. It's symmetric as long as you suppose that the above are the only requirements. However, there's another requirement, which is that if you do try to drop the index partition directly, we would like the error message to suggest dropping the master index, not the table. The only way to be sure about what will be suggested is if there can be only one "owning object". Also, I am suspicious that this implementation fails on point 3 anyway. It looks to me like if a recursive drop reaches the index partition from a dependency other than either the table partition or the master index, it will let the index partition be dropped by itself. Ordinarily, this would likely not matter because the index partition would share any other dependencies (opclasses, for instance) with one or the other owning object. But I don't think it's too hard to construct cases where that's not true. If nothing else, it looks like ALTER OBJECT DEPENDS ON EXTENSION can be used to attach a random dependency to just about anything. regards, tom lane