Date: Wed, 27 May 2020 16:48:53 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrey Klychkov <aaklychkov@mail.ru>,
	Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
	pgsql-bugs@lists.postgresql.org
Subject: Re: Re[2]: 
Message-ID: <20200527074736.GG103662@paquier.xyz>
References: <1590486572.205117372@f500.i.mail.ru>
 <cca87255-7dea-6aac-2e9a-35dfe3776122@2ndquadrant.com>
 <1590501239.839686286@f437.i.mail.ru>
 <17907.1590504619@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="Bg2esWel0ueIH/G/"
Content-Disposition: inline
In-Reply-To: <17907.1590504619@sss.pgh.pa.us>
Precedence: bulk


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

On Tue, May 26, 2020 at 10:50:19AM -0400, Tom Lane wrote:
> 2. Is reindexdb handling the failure sanely?  While I'd agree that
> this behavior isn't especially desirable, it's the price of using
> REINDEX CONCURRENTLY.  On failure, you're expected to clean up
> manually by removing the leftover invalid index.  Perhaps the
> documentation isn't clear enough about that, but I don't see a
> bug there.

There is a paragraph about the handling of invalid indexes on the
reindex page:
https://www.postgresql.org/docs/devel/sql-reindex.html#SQL-REINDEX-CONCURRENTLY
"The recommended recovery method in such cases is to drop the invalid
index and try again to perform REINDEX CONCURRENTLY. The concurrent
index created during the processing has a name ending in the suffix
ccnew, or ccold if it is an old index definition which we failed to
drop. Invalid indexes can be dropped using DROP INDEX, including
invalid toast indexes."
--
Michael

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

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAl7OG2UACgkQnvQgOdby
QH1x2hAAoX/yR+06NwPkiCWxq8S0mqUh7m00KUzi5A3Sb24FQei/ew3AatCN7kxn
M3LEyEzfJ5+KZbEej7cWif9gqb8oh4JGtEykFZujrbrnOjD3QiphBA1i2mDtMI+S
mzQ2WRfJr8JFJ1C7D/RUPAMgAIh/8H7IrHkYYqzT+/oi8GHh4imOL152KLj2bERf
+r3FfKk/kSfUrXRYkA7UE2vsqpzoROdzF9J5QCMjgIdl3xIF+1OpkII2sTDnfzj2
5cfz9TVvlV5sPv8/XiZ36OKKmra2WSssajx4SP/NJBJ9IbgFGpJ9GJScfizJl/Wt
g/0Yv49ulmvwXxgaxtK1rzWUTIeGOyUZIJ72v7qorLnq68uYhwhWjUXels5wwAYb
XlcmpNhP9umX67mrMh2NDdaCryYewxdaMTwyjK8I/8YyKgNxQ/BqpLYgxNnP4RJ0
17wHj+r335Y/Bwdbc5+8hia11nTTk3NEmqtJl1Gu2BzWyQa0G9fm8ukqWMsoiVsN
8XFAqtsKcwJHRHMCEwxNahQf7Cb0oaf9p8eT07G/02Rn02rHRcx8bfZBZ0uL4diS
8Yio+dSwBTu3xSgE0lixZupqzDruGwCIW48xDSkhW3jxQLDCs6EfyXf4qeKZsjGI
8fEAEiLbdH0o/eo+1N/GHdEEnEepd7NTwDmfhWnhMdPtJDgAg20=
=w8aG
-----END PGP SIGNATURE-----

--Bg2esWel0ueIH/G/--