Re: REINDEX blocks virtually any queries but some prepared queries.

On 4/8/22 02:22, Michael Paquier wrote:
> On Thu, Apr 07, 2022 at 05:29:36PM +0200, Guillaume Lelarge a écrit :
>> Le jeu. 7 avr. 2022 à 15:44, Frédéric Yhuel <frederic(dot)yhuel(at)dalibo(dot)com> a écrit :
>>> On 4/7/22 14:40, Justin Pryzby wrote:
>>> Thank you Justin! I applied your fixes in the v2 patch (attached).
>>
>> v2 patch sounds good.
>
> The location of the new sentence and its wording seem fine to me. So
> no objections from me to add what's suggested, as suggested. I'll
> wait for a couple of days first.
>

Thank you Michael.

>>> Indeed ;) That being said, REINDEX CONCURRENTLY could give you an
>>> invalid index, so sometimes you may be tempted to go for a simpler
>>> REINDEX, especially if you believe that the SELECTs won't be blocked.
>>
>> Agreed.
>
> There are many factors to take into account, one is more expensive
> than the other in terms of resources and has downsides, downsides
> compensated by the reduction in the lock requirements. There are
> cases where REINDEX is a must-have, as CONCURRENTLY does not support
> catalog indexes, and these tend to be easily noticed when corruption
> spreads around.

Indeed!

Best regards,
Frédéric