Re: REINDEX CONCURRENTLY unexpectedly fails

--d6iqOn7HZPWKXx18
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Heikki,

On Thu, Jan 09, 2020 at 12:06:19PM +0900, Michael Paquier wrote:
> As the patch has been heavily modified, I am switching it back to
> "Needs Review" for now and I'd like to discuss more about the lock
> upgrade risks, particularly if it is considered worth the effort for
> temporary relations.  Thoughts are welcome.=20

You are registered as a reviewer for this patch:
https://commitfest.postgresql.org/26/2358/

Are you planning to look at it?  Do you have some thoughts to share
about what I wrote previously?

Discarding the lock upgrade considerations is possible.  Another
approach would be, instead of ignoring CONCURRENTLY for temporary
tables, to fail if the operation is run, and ignore these when a
dabatase-wide reindex concurrently happens.  This was not liked much
at the beginning of the thread though.
--
Michael

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

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAl4dgAwACgkQnvQgOdby
QH3Vug//U4FXvgk7gxDOu+TVnlpwgMasc6ohNIsvCwyZ13Lggzo4a8D7+BlUL4T5
yzGWYcoYHeIcIpp9iXi7iWLGi278O0b5LA4lQT39/rug2RSsvb/rdA52t+NZau+y
xlb0N+cF7m55Ah0GBXx9bT+r7MF1wXjZfrCsn6pMELWJ6sr45olIg9VOrvz7iyBN
p7d7IhhLfJH6llh7ZqCrLuffLj4c8fVPKvq0fAhnkVovb7e8MtPc1YyIxlJBRbNI
E38P2231CHGz51PqCNPo8mzVdXg56897a3Nk0ClWwQu6exl3fXxJbkn193ICprR4
5CVT3bKCxPGGI3Pz0AyadA99I2WfsgwjmMW2ja7wyPSduuWHID7HZYVfq4gr4tJw
RPTQvqDv1iU5ddrVBF9jwuf3mYNM8kfYuK7835k5K2uLziTiBYS0HA4gY8ya9bF8
i3qkvlNZtR5RJtSa6hw9i+tBKD86DCfBI/43W9GUegUgmRHl3gLpqpi6Ut4Gr9DJ
0ruqoy9bfpd54YtxfdT1BGenN451n22l+SFJfr2H1l9akGstnjY/7C23qWVNwePc
uA5RG+BTYVai/+Q8E3kQ25ashAuIJnLcNPb7m9k7amCPvOWYp+c1hld617w48es+
O4ihl42eEmm0PEB+t3etXkPJJTLx81dOT+3vC2UqKOujcDRmUgw=
=IqqR
-----END PGP SIGNATURE-----

--d6iqOn7HZPWKXx18--