Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nc6y1-0003W9-Mw for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Apr 2022 14:49:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nc6y0-0003uj-7J for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Apr 2022 14:49:04 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nc6xz-0003uZ-Te for pgsql-hackers@lists.postgresql.org; Wed, 06 Apr 2022 14:49:03 +0000 Received: from mail1.dalibo.net ([212.83.143.11] helo=mail.dalibo.com) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nc6xx-0006jF-5R for pgsql-hackers@lists.postgresql.org; Wed, 06 Apr 2022 14:49:03 +0000 Received: from [192.168.1.16] (abordeaux-651-1-135-93.w90-16.abo.wanadoo.fr [90.16.230.93]) by mail.dalibo.com (Postfix) with ESMTPSA id 887161F955 for ; Wed, 6 Apr 2022 16:48:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dalibo.com; s=a; t=1649256538; bh=JAQ3QqqzUIj0+MxiA1U5UjhMzhi70WHT5J0D0gk5UUo=; h=Date:From:To:Subject:From; b=NheClhEIRmvtNiz3MsN66urJP1jpDhjYQdmTuH5UihzOeT/Hr0xVwHugdvlP5Wtv0 Jp0ifr7MlRjxZwKQfU5u6/G7EQklt8HDw8w0efeO+Ls0MPWoWewYshTGiSaZAi7Tyq V7lfuwbieYXheiYLaLeq8NTbub/qCzb20wc74j40= Message-ID: <65d08718-6f11-978a-4b5a-72b807d4c663@dalibo.com> Date: Wed, 6 Apr 2022 16:48:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US From: =?UTF-8?Q?Fr=c3=a9d=c3=a9ric_Yhuel?= To: pgsql-hackers@lists.postgresql.org Subject: REINDEX blocks virtually any queries but some prepared queries. Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hello, From the documentation (https://www.postgresql.org/docs/current/sql-reindex.html#id-1.9.3.162.7), it sounds like REINDEX won't block read queries that don't need the index. But it seems like the planner wants to take an ACCESS SHARE lock on every indexes, regardless of the query, and so REINDEX actually blocks any queries but some prepared queries whose plan have been cached. I wonder if it is a bug, or if the documentation should be updated. What do you think? Here is a simple demo (tested with postgres 10 and master): Session #1 =========================================================== srcpg@postgres=# CREATE TABLE flights (id INT generated always as identity, takeoff DATE); CREATE TABLE srcpg@postgres=# INSERT INTO flights (takeoff) SELECT date '2022-03-01' + interval '1 day' * i FROM generate_series(1,1000) i; INSERT 0 1000 srcpg@postgres=# CREATE INDEX ON flights(takeoff); CREATE INDEX srcpg@postgres=# BEGIN; BEGIN srcpg@postgres=# REINDEX INDEX flights_takeoff_idx ; REINDEX Session #2 =========================================================== srcpg@postgres=# SELECT pg_backend_pid(); pg_backend_pid ---------------- 4114695 srcpg@postgres=# EXPLAIN SELECT id FROM flights; --> it blocks Session #3 =========================================================== srcpg@postgres=# SELECT locktype, relname, mode, granted FROM pg_locks LEFT JOIN pg_class ON (oid = relation) WHERE pid = 4114695; locktype | relname | mode | granted ------------+---------------------+-----------------+--------- virtualxid | ∅ | ExclusiveLock | t relation | flights_takeoff_idx | AccessShareLock | f relation | flights | AccessShareLock | t