Re: Support for REINDEX CONCURRENTLY

On Fri, Mar 8, 2013 at 1:41 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:

> On Thu, Mar 7, 2013 at 7:19 AM, Andres Freund <andres(at)2ndquadrant(dot)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