From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)
Date: Thu, 17 Jan 2019 16:54:36 -0500
Message-ID: <15908.1547762076@sss.pgh.pa.us> (raw)
In-Reply-To: <15190.1547757720@sss.pgh.pa.us>
References: <CAH2-WzmYbkT6e9B1jWApV5HcApUZqC==yoC4VTi7TBs007Ki+g@mail.gmail.com>
<20181218212053.4vqcmmcicbzr2jyc@alvherre.pgsql>
<CAH2-WzkMmRkXsWaVZ+VEbKdcKRcTuxu5ogVVH1SARqVuTuQKHA@mail.gmail.com>
<21925.1545171102@sss.pgh.pa.us>
<CAH2-Wz=rmUGgdp8K-FB1VRQngHk7MdtKvEATFQ_pP3_N257t8g@mail.gmail.com>
<22791.1545171984@sss.pgh.pa.us>
<CAH2-WzmQuksC_sWR8Z0aqxAVC6bBAcwU3bHv=rbf8Hp1RdJjvA@mail.gmail.com>
<15190.1547757720@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
Attachments:
[text/x-diff] dont-report-subobjects-duplicatively-1.patch (2.6K, ../15908.1547762076@sss.pgh.pa.us/2-dont-report-subobjects-duplicatively-1.patch)
download | inline diff:diff --git a/src/backend/catalog/dependency.c b/src/backend/catalog/dependency.cindex 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 object */
/* 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 = 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 = addrs->extras + i;
! thisextra->flags |= 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 != 0 (flags == 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 = addrs->extras + i;
! if (flags)
! thisextra->flags |= (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 |= 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 |= (flags | DEPFLAG_SUBOBJECT);
}
}
}
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, pg@bowt.ie, alvherre@2ndquadrant.com
Subject: Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)
In-Reply-To: <15908.1547762076@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox