Peter Geoghegan <p...@bowt.ie> writes: > On Thu, Jan 17, 2019 at 12:42 PM Tom Lane <t...@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