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 1gZK4Q-0000ig-Tj for pgsql-hackers@arkaria.postgresql.org; Tue, 18 Dec 2018 18:26:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gZK4N-0007dP-HF for pgsql-hackers@arkaria.postgresql.org; Tue, 18 Dec 2018 18:26:15 +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 1gZK4N-0007VH-5W for pgsql-hackers@lists.postgresql.org; Tue, 18 Dec 2018 18:26:15 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gZK4G-0002w1-0W for pgsql-hackers@postgresql.org; Tue, 18 Dec 2018 18:26:13 +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 wBIIQ3Yq005125; Tue, 18 Dec 2018 13:26:03 -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: <20181218180707.id4chuplqoqzypwe@alvherre.pgsql> References: <20181218180707.id4chuplqoqzypwe@alvherre.pgsql> Comments: In-reply-to Alvaro Herrera message dated "Tue, 18 Dec 2018 15:07:07 -0300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5123.1545157563.1@sss.pgh.pa.us> Date: Tue, 18 Dec 2018 13:26:03 -0500 Message-ID: <5124.1545157563@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Alvaro Herrera writes: > On 2018-Nov-05, Peter Geoghegan wrote: >> I've realized that my patch to make nbtree keys unique by treating >> heap TID as a tie-breaker attribute must use ASC ordering, for reasons >> that I won't go into here. Now that I'm not using DESC ordering, there >> are changes to a small number of DROP...CASCADE messages that leave >> users with something much less useful than what they'll see today -- >> see attached patch for full details. Some of these problematic cases >> involve partitioning: > Is there any case of this that doesn't involve DEPENDENCY_INTERNAL_AUTO > entries? I wonder if I just haven't broken the algorithm when > introducing that, and I worry that we're adding a complicated kludge to > paper over that problem. Maybe instead of the depcreate contortions we > need to adjust the algorithm to deal with INTERNAL_AUTO objects in a > different way. Yeah, I've been wondering about that as well. The original intention for dependency traversal was that it'd work independently of the ordering of entries in pg_depend. If it's not doing so, I'd call that a bug in dependency traversal rather than something the index code needs to be responsible for. (Note that this statement doesn't disagree with our issues about needing to suppress dependency reports in the regression tests; that's because the order of reports about independent objects can legitimately depend on the index order. But there shouldn't be any semantic differences.) regards, tom lane