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 1gkFcc-0001tb-G2 for pgsql-hackers@arkaria.postgresql.org; Thu, 17 Jan 2019 21:54:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gkFca-0001qi-Ev for pgsql-hackers@arkaria.postgresql.org; Thu, 17 Jan 2019 21:54:44 +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 1gkFca-0001mm-6F for pgsql-hackers@lists.postgresql.org; Thu, 17 Jan 2019 21:54:44 +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 1gkFcY-0002On-2h for pgsql-hackers@postgresql.org; Thu, 17 Jan 2019 21:54:43 +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 x0HLsa2H015909; Thu, 17 Jan 2019 16:54:37 -0500 From: Tom Lane To: Peter Geoghegan cc: Alvaro Herrera , PostgreSQL Hackers Subject: Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages) In-reply-to: <15190.1547757720@sss.pgh.pa.us> References: <20181218212053.4vqcmmcicbzr2jyc@alvherre.pgsql> <21925.1545171102@sss.pgh.pa.us> <22791.1545171984@sss.pgh.pa.us> <15190.1547757720@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Thu, 17 Jan 2019 15:42:00 -0500" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <15874.1547762019.0@sss.pgh.pa.us> Date: Thu, 17 Jan 2019 16:54:36 -0500 Message-ID: <15908.1547762076@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15874.1547762019.1@sss.pgh.pa.us> I wrote: > I propose that we handle this case by adding a new DEPFLAG_IS_SUBOBJECT > flag to the column object's flags, denoting that we know the whole table > will be dropped later. The only effect of this flag is to suppress > reporting of the column object in reportDependentObjects. Here's a proposed patch for that bit. As expected, it seems to eliminate the variation in number-of-cascaded-drops-reported under ignore_system_indexes. I do not see any regression outputs change otherwise. regards, tom lane ------- =_aaaaaaaaaa0 Content-Type: text/x-diff; name="dont-report-subobjects-duplicatively-1.patch"; charset="us-ascii" Content-ID: <15874.1547762019.2@sss.pgh.pa.us> Content-Description: dont-report-subobjects-duplicatively-1.patch Content-Transfer-Encoding: quoted-printable diff --git a/src/backend/catalog/dependency.c b/src/backend/catalog/depend= ency.c index 3529084..6b8c735 100644 *** a/src/backend/catalog/dependency.c --- b/src/backend/catalog/dependency.c *************** typedef struct *** 102,107 **** --- 102,108 ---- #define DEPFLAG_INTERNAL 0x0008 /* reached via internal dependency */ #define DEPFLAG_EXTENSION 0x0010 /* reached via extension dependency */ #define DEPFLAG_REVERSE 0x0020 /* reverse internal/extension link */ + #define DEPFLAG_SUBOBJECT 0x0040 /* subobject of another deletable objec= t */ = = /* expansible list of ObjectAddresses */ *************** reportDependentObjects(const ObjectAddre *** 886,891 **** --- 887,896 ---- if (extra->flags & DEPFLAG_ORIGINAL) continue; = + /* Also ignore sub-objects; we'll report the whole object elsewhere */ + if (extra->flags & DEPFLAG_SUBOBJECT) + continue; + = objDesc =3D getObjectDescription(obj); = /* *************** object_address_present_add_flags(const O *** 2320,2332 **** * DROP COLUMN action even though we know we're gonna delete * the table later. * * Because there could be other subobjects of this object in * the array, this case means we always have to loop through * the whole array; we cannot exit early on a match. */ ObjectAddressExtra *thisextra =3D addrs->extras + i; = ! thisextra->flags |=3D flags; } } } --- 2325,2343 ---- * DROP COLUMN action even though we know we're gonna delete * the table later. * + * What we can do, though, is mark this as a subobject so that + * we don't report it separately, which is confusing because + * it's unpredictable whether it happens or not. But do so + * only if flags !=3D 0 (flags =3D=3D 0 is a read-only probe). + * * Because there could be other subobjects of this object in * the array, this case means we always have to loop through * the whole array; we cannot exit early on a match. */ ObjectAddressExtra *thisextra =3D addrs->extras + i; = ! if (flags) ! thisextra->flags |=3D (flags | DEPFLAG_SUBOBJECT); } } } *************** stack_address_present_add_flags(const Ob *** 2374,2380 **** * object_address_present_add_flags(), we should propagate * flags for the whole object to each of its subobjects. */ ! stackptr->flags |=3D flags; } } } --- 2385,2392 ---- * object_address_present_add_flags(), we should propagate * flags for the whole object to each of its subobjects. */ ! if (flags) ! stackptr->flags |=3D (flags | DEPFLAG_SUBOBJECT); } } } ------- =_aaaaaaaaaa0--