Re: BUG #16594: DROP INDEX CONCURRENTLY fails on partitioned table with a non helpful error message.

On Wed, Aug 26, 2020 at 08:11:16PM +0000, PG Bug reporting form wrote:
> After more digging the user elaborated that this is in fact a partitioned
> table.

This error happens in index_drop() as of index.c, where we need to
assume that the index drop is the first action happening in a
transaction.  Now comes the tricky problem: when you drop the index of
a partitioned table, the dependency machinery needs to find the set of
dependent objects, and this assigns a transaction ID for the list of
partitions.

Still, it seems to me that we are far from being able to support fully
this operation on partitioned indexes, and we need to do more than
what we have now if we want this feature.  So I think that the
concurrent drop of partitioned indexes should respect the following
flow:
1) Drop all the dependencies for the partition tree in a single,
first, transaction.
2) Drop each index after that, in its own two sets of transactions for
each entry, one to clear indisvalid and a second one to do the actual
drop.

The whole operation should make sure that we still have a fully
consistent state in the catalogs for any transaction, so as we have no
risk of finishing with a semi-broken partition tree if the thing fails
while processing for a reason or another.  As long as 1) is not
implemented, I don't think that this can really be safe, still this
requires careful thinking in the way we gather the list of indexes to
drop beforehand.

The error message is really confusing though, so for now I would
recommend to just drop an error if trying the operation on a
partitioned table, and we also do that now for CREATE INDEX
CONCURRENTLY.
--
Michael