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 19:40:26 -0500
Message-ID: <24211.1547772026@sss.pgh.pa.us> (raw)
In-Reply-To: <CAH2-WznWGEaEBX=PqwdXOS_WwcRS-kB5zA5kdrmqXKmP7b6FuA@mail.gmail.com>
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>
<CAH2-WznWGEaEBX=PqwdXOS_WwcRS-kB5zA5kdrmqXKmP7b6FuA@mail.gmail.com>
Peter Geoghegan <pg@bowt.ie> writes:
> On Thu, Jan 17, 2019 at 12:42 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Now, perhaps we should make such stability a design goal, as it'd allow
>> us to get rid of some "suppress the cascade outputs" hacks in the
>> regression tests. But it's a bit of a new feature. If we wanted to
>> do that, I'd be inclined to do it by absorbing all the pg_depend entries
>> for a particular object into an ObjectAddress array and then sorting
>> them before we process them. The main stumbling block here is "what
>> would the sort order be?". The best idea I can come up with offhand
>> is to sort by OID, which at least for regression test purposes would
>> mean objects would be listed/processed more or less in creation order.
> I think that we might as well have a stable order. Maybe an explicit
> sort step is unnecessary -- we can actually rely on scan order, while
> accepting you'll get a different order with "ignore_system_indexes=on"
> (though without getting substantively different/incorrect messages).
Yeah, that's the policy we've followed so far, but I remain concerned
about its effects on the regression tests. There are a lot of places
where we print full DROP CASCADE output because "it hasn't failed yet".
I fear every one of those is a gotcha that's waiting to bite us.
Also, is index scan order really guaranteed for equal-keyed items?
It isn't today, and I didn't think your patches were going to make
it so.
> I'm slightly concerned that an explicit sort step might present
> difficulties in extreme cases. How much memory are we prepared to
> allocate, just to get a stable order?
We're going to stick all these items into an ObjectAddress array anyway,
so at worst it'd be 2X growth, most likely a lot less since we'd only
be sorting one level of dependency at a time.
> As I've pointed out a couple of times already, we can add a 4 byte
> tie-breaker column to both pg_depend indexes without increasing the
> size of the on-disk representation, since the extra space is already
> lost to alignment (we could even add a new 4 byte column to the table
> without any storage overhead, if that happened to make sense).
Meh ... where do you get the 4-byte value from?
regards, tom lane
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: <24211.1547772026@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