Date: Thu, 27 Aug 2020 10:00:54 +0900
From: Michael Paquier <michael@paquier.xyz>
To: jan.mussler@zalando.de, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #16594: DROP INDEX CONCURRENTLY fails on partitioned table
 with a non helpful error message.
Message-ID: <20200827010054.GK2017@paquier.xyz>
References: <16594-d2956ca909585067@postgresql.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="MSd2ShuMixI0uVaZ"
Content-Disposition: inline
In-Reply-To: <16594-d2956ca909585067@postgresql.org>
Precedence: bulk


--MSd2ShuMixI0uVaZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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

--MSd2ShuMixI0uVaZ
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAl9HBcYACgkQnvQgOdby
QH0GTA/9FmhoGV8OaZiAqZhxpuy44WYI1h/LTw3XrucSOY5UnKX1Y/QwBUTu0z73
k8u8n9AEXes9Zhzz2Mqh5JytDHQ4lrWdiQppGR8H4vERwr49WKPXgz7l8NLWHys1
CwX5Apem+zZ7oK+MPY7a7bGFIIuBoA2ryIGZHv3kJp81jIrL2s3pg21TzIeiRzn+
aZBkR7NJ92AxmbG6KNoLB9nfLW4LWx0FS/0LK5NfSkhN5taQdwin1jFv11N+NOka
zGdnPdr0w6xy7JLyIhH1Mr+2JfCActzwwNDXI6B2mErcyHrO0fpN0vxOLCajzxMj
d3jZ9RTq3guQBu9kI1i6xYzFQjyEV2bKAvMsRmRxxG0rGqVdiY5ZrbXch6zXE4ly
/kfZGPpwcD6J5Leu2c01nA7j7gWjK2hYl56hNZJm73raoES2y6Cnm35X/fQKOWvS
Y70HzWCVIefiipmBz1kPCzeDolm5inHmBMI9FGzKvq/wKVd0yq5Dm9MWs3RoqB1w
aFYhu8Hg+ogM6iPNyIOEEe07vIr8DKVFVw0JAiagT3WunruFKYGWPDJWboP+plo6
85IYqljRIWGV4qMZ5Ridon0O1+6cIDunlRnTr7LrR8xrzK0YAH/5zQven0eUf9EY
xLnmxdPieHFyMtjd6ZF+yyXI0l9uCAHRPKTlIWwj8HINVQvRKhM=
=4apG
-----END PGP SIGNATURE-----

--MSd2ShuMixI0uVaZ--