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

From Michael Paquier
Subject Re: REINDEX blocks virtually any queries but some prepared queries.
Date
Msg-id Yk+ATh9TbWHjtXfp@paquier.xyz
Whole thread Raw
In response to Re: REINDEX blocks virtually any queries but some prepared queries.  (Guillaume Lelarge <guillaume@lelarge.info>)
Responses Re: REINDEX blocks virtually any queries but some prepared queries.  (Frédéric Yhuel <frederic.yhuel@dalibo.com>)
List pgsql-hackers
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.

>> 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.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: logical decoding and replication of sequences
Next
From: Justin Pryzby
Date:
Subject: Re: Collecting statistics about contents of JSONB columns