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 1gkGRk-0004DB-97 for pgsql-hackers@arkaria.postgresql.org; Thu, 17 Jan 2019 22:47:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gkGRi-00052n-So for pgsql-hackers@arkaria.postgresql.org; Thu, 17 Jan 2019 22:47:34 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gkGRi-00052g-IZ for pgsql-hackers@lists.postgresql.org; Thu, 17 Jan 2019 22:47:34 +0000 Received: from mail-qt1-x843.google.com ([2607:f8b0:4864:20::843]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gkGRb-0002ui-6R for pgsql-hackers@postgresql.org; Thu, 17 Jan 2019 22:47:33 +0000 Received: by mail-qt1-x843.google.com with SMTP id p17so13266591qtl.5 for ; Thu, 17 Jan 2019 14:47:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=VVnbF4S41/1Jz5CE5NkAFdSnTMOGuFmGXZ2SGLVUyUU=; b=p3uhkj5ecIEp3ftr8T3UBYQMiYVYX9leULajhhPiBd+Oh0eT4912pe8FkEU91/GCN4 aj9lhW+60bwRGqGNUyRI3+r9pf6Jj6dveYgq1gVxKAxMAeGXnN9EZdqJKFkqozGqyQuQ o+H9tc9k3BnvwCMwR7BiwCrV5k5MiAMPLAo6wL+7bYuANi1RjGLKwuNHNAB5v2CFD7HV 7Pg9VC16mq25EarjkeugxtnaB8Pz2Hv4LQz36xxGX7EdwtbxpZOZtZEOY3viip9QtWKT 5SCDy/kKn9UOxhs8BMyIBf4OhYkz0wDQQHg0VpB2jHeaxHjq2NgRBpHZshfzEEI3M2KT pSKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=VVnbF4S41/1Jz5CE5NkAFdSnTMOGuFmGXZ2SGLVUyUU=; b=iFUAbcvEKr5sK5ZyYTMl/SxeSxzJ83DJeov0OfYFjC3EsFt2hy1yEgZ/LduJpiB2Bj ye8+oTZXx5y1N5ShfaZUC1cEnALsVjeeF08ga5Y2bWEG43RatE1XKnGMZ6fBcdyNaRvE FIvcCD6DNy21Qtdkc1CRSk0HxixYemiTuSngn+rcq6vpKkavHOCVps/LZAbEBOeK2xfH 45FUZItVEC7zdWFnmfa1Os7r8ydBIJ030xZBPPmRdoYawjL+QeHtf613TE9PWEYb6ndD +6rylKmVpZ31d61ntvemF1JjITFL3uO5qeY3estl8FoEuzFGRPk4A/930JhDZLn/kBx7 dtlQ== X-Gm-Message-State: AJcUukffxgicVsBOwFm3tyiWeyHTvp205u8T3r6zhwcz9cPzFCLZ2Gvy odyJcnYDBKHwuElobsRChdSdDQ== X-Google-Smtp-Source: ALg8bN4liCX1YsBBPFTC0w784kbh6mqeQMZ9CyaJSFviq1DxyUp15qFmAlfc0tJoZ8U4wcVkm4j8iA== X-Received: by 2002:a0c:afa1:: with SMTP id s30mr13399740qvc.53.1547765246318; Thu, 17 Jan 2019 14:47:26 -0800 (PST) Received: from alvin.alvh.no-ip.org ([190.121.29.3]) by smtp.gmail.com with ESMTPSA id f31sm55931321qtc.42.2019.01.17.14.47.25 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 17 Jan 2019 14:47:25 -0800 (PST) Received: by alvin.alvh.no-ip.org (Postfix, from userid 1000) id B732095C; Thu, 17 Jan 2019 19:47:23 -0300 (-03) Date: Thu, 17 Jan 2019 19:47:23 -0300 From: Alvaro Herrera To: Tom Lane Cc: Peter Geoghegan , PostgreSQL Hackers Subject: Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages) Message-ID: <201901172247.uqvtve6ekpvh@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <17113.1547763927@sss.pgh.pa.us> User-Agent: NeoMutt/20180716-1013-2c1e88 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2019-Jan-17, Tom Lane wrote: > Alvaro Herrera writes: > > On 2019-Jan-17, Tom Lane wrote: > >> DEPENDENCY_INTERNAL_AUTO, however, broke this completely, as the code > >> has no hesitation about making multiple entries of that kind. After > >> rather cursorily looking at that code, I'm leaning to the position > >> that DEPENDENCY_INTERNAL_AUTO is broken-by-design and needs to be > >> nuked from orbit. In the cases where it's being used, such as > >> partitioned indexes, I think that probably the right design is one > >> DEPENDENCY_INTERNAL dependency on the partition master index, and > >> then one DEPENDENCY_AUTO dependency on the matching partitioned table. > > > As I recall, the problem with that approach is that you can't drop the > > partition when a partitioned index exists, because it follows the link > > to the parent index and tries to drop that. > > 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. I'm now wondering if it would work to have the one from index partition to table partition as DEPENDENCY_AUTO and the one from index partition to parent index as DEPENDENCY_INTERNAL_AUTO. I stared at a lot of possible dependency graphs, but I'm not sure if this one was one of them. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services