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
-
doc: Clarify behavior of query planner locking with REINDEX
- 8ac700acffc7 15.0 landed