Re: REINDEX blocks virtually any queries but some prepared queries. - Mailing list pgsql-hackers

From Frédéric Yhuel
Subject Re: REINDEX blocks virtually any queries but some prepared queries.
Date
Msg-id dcdfea80-9f7a-66f7-95d0-b38b976c2c4d@dalibo.com
Whole thread Raw
In response to Re: REINDEX blocks virtually any queries but some prepared queries.  (Michael Paquier <michael@paquier.xyz>)
Responses Re: REINDEX blocks virtually any queries but some prepared queries.  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers

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.yhuel@dalibo.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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: remove more archiving overhead
Next
From: Amul Sul
Date:
Subject: Re: [Patch] ALTER SYSTEM READ ONLY