From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
        PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Fixing findDependentObjects()'s dependency on scan order
 (regressions in DROP diagnostic messages)
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>
Comments: In-reply-to Peter Geoghegan <pg@bowt.ie>
	message dated "Thu, 17 Jan 2019 16:03:27 -0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <24210.1547772026.1@sss.pgh.pa.us>
Date: Thu, 17 Jan 2019 19:40:26 -0500
Message-ID: <24211.1547772026@sss.pgh.pa.us>
Precedence: bulk

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