Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)
Date
Msg-id 19220.1547767251@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages)  (Peter Geoghegan <pg@bowt.ie>)
Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2019-Jan-17, Tom Lane wrote:
>> Hm.  Still, I can't believe that it's appropriate for a partitioned index
>> to have exactly the same kind of dependency on the master index as it
>> does on the associated table.

> So there are three necessary features:
> * The partition can be dropped, which takes down the index partition
> * The master index can be dropped, which takes down the index partition
> * The index partition must never be allowed to be dropped on its own.

> There is a symmetry to these that led me to have the same kind of
> dependency from the index partition to the other two.

It's symmetric as long as you suppose that the above are the only
requirements.  However, there's another requirement, which is that
if you do try to drop the index partition directly, we would like
the error message to suggest dropping the master index, not the
table.  The only way to be sure about what will be suggested is
if there can be only one "owning object".

Also, I am suspicious that this implementation fails on point 3
anyway.  It looks to me like if a recursive drop reaches the
index partition from a dependency other than either the table
partition or the master index, it will let the index partition
be dropped by itself.  Ordinarily, this would likely not matter
because the index partition would share any other dependencies
(opclasses, for instance) with one or the other owning object.
But I don't think it's too hard to construct cases where that's
not true.  If nothing else, it looks like ALTER OBJECT DEPENDS ON
EXTENSION can be used to attach a random dependency to just
about anything.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD
Next
From: Tom Lane
Date:
Subject: Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD