Re: Support for REINDEX CONCURRENTLY - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Support for REINDEX CONCURRENTLY
Date
Msg-id CAB7nPqRCgfJA-_nj60krhCd3pnnp0ibP=P0_0Xa2XEWuvdwe2g@mail.gmail.com
Whole thread Raw
In response to Re: Support for REINDEX CONCURRENTLY  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: Support for REINDEX CONCURRENTLY  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers


On Fri, Mar 8, 2013 at 1:41 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
On Thu, Mar 7, 2013 at 7:19 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> The strange think about "hoge_pkey_cct_cct" is that it seems to imply
> that an invalid index was reindexed concurrently?
>
> But I don't see how it could happen either. Fujii, can you reproduce it?

Yes, I can even with the latest version of the patch. The test case to
reproduce it is:

(Session 1)
CREATE TABLE hoge (i int primary key);
INSERT INTO hoge VALUES (generate_series(1,10));

(Session 2)
BEGIN;
SELECT * FROM hoge;
(keep this session as it is)

(Session 1)
SET statement_timeout TO '1s';
REINDEX TABLE CONCURRENTLY hoge;
\d hoge
REINDEX TABLE CONCURRENTLY hoge;
\d hoge
I fixed this problem in the patch attached. It was caused by 2 things:
- The concurrent index was seen as valid from other backend between phases 3 and 4. So the concurrent index is made valid at phase 4, then swap is done and finally marked as invalid. So it remains invalid seen from the other sessions.
- index_set_state_flags used heap_inplace_update, which is not completely safe at swapping phase, so I had to extend it a bit to use a safe simple_heap_update at swap phase.

Regards,
--
Michael
Attachment

pgsql-hackers by date:

Previous
From: Kohei KaiGai
Date:
Subject: Re: [v9.3] OAT_POST_ALTER object access hooks
Next
From: Heikki Linnakangas
Date:
Subject: Re: SP-GiST for ranges based on 2d-mapping and quad-tree