From: Tom Lane <tgl@sss.pgh.pa.us>
To: Satoshi Nagayasu <snaga@uptime.jp>
cc: pgsql-docs@postgresql.org
Subject: Re: REINDEX and blocking SELECT queries
In-reply-to: 
 <CAA8sozcK9eOo0Cj0ufBpAYi=oL2cJ-T9T7JN-_CqpYSWZ0GDcg@mail.gmail.com>
References: 
 <CAA8sozcK9eOo0Cj0ufBpAYi=oL2cJ-T9T7JN-_CqpYSWZ0GDcg@mail.gmail.com>
Comments: In-reply-to Satoshi Nagayasu <snaga@uptime.jp>
	message dated "Fri, 09 Sep 2016 20:48:23 +0900"
Date: Fri, 09 Sep 2016 09:41:36 -0400
Message-ID: <19413.1473428496@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-docs-owner@postgresql.org

Satoshi Nagayasu <snaga@uptime.jp> writes:
> According to the manual, running REINDEX does not take any locks
> on the parent table which block read operations.
> Actually, REINDEX blocks SELECT queries, maybe in the planning phase.

Hm.  REINDEX does take out only ShareLock on the table, which would not
block DML, but it takes out AccessExclusiveLock on the index.  That
blocks the planner's attempts to acquire information about the table's
indexes.

In the case of an update query I think there's little we can do about
this; the executor would have to update the index anyway.  For a pure
SELECT, you could imagine having the planner do a conditional lock acquire
and ignore the index if that fails.  Would that be better than blocking?
Not sure.  You could end up with a really bad plan if the index was
critical for efficient processing of the query.

			regards, tom lane


-- 
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs