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

Guillaume Lelarge <guillaume@lelarge.info>

From: Guillaume Lelarge <guillaume@lelarge.info>
To: Frédéric Yhuel <frederic.yhuel@dalibo.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>, Peter Geoghegan <pg@bowt.ie>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-04-07T15:29:36Z
Lists: pgsql-hackers
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:
> > On Thu, Apr 07, 2022 at 01:37:57PM +0200, Frédéric Yhuel wrote:
> >> Maybe something along this line? (patch attached)
> > Some language fixes.
>
> Thank you Justin! I applied your fixes in the v2 patch (attached).
>
>
v2 patch sounds good.


> > I didn't verify the behavior, but +1 to document the practical
> consequences.
> > I guess this is why someone invented REINDEX CONCURRENTLY.
> >
>
> 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.


-- 
Guillaume.

Commits

  1. doc: Clarify behavior of query planner locking with REINDEX