Horton

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

Frédéric Yhuel <frederic.yhuel@dalibo.com>

View thread View on postgr.es
From: Frédéric Yhuel <frederic.yhuel@dalibo.com>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Peter Geoghegan <pg@bowt.ie>, pgsql-hackers@lists.postgresql.org
Date: 2022-04-07T13:43:57Z
Lists: pgsql-hackers

Attachments


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

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

Commits

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