On Fri, Mar 8, 2013 at 10:00 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > > > On Fri, Mar 8, 2013 at 1:41 AM, Fujii Masao <masao.fu...@gmail.com> wrote: >> >> On Thu, Mar 7, 2013 at 7:19 AM, Andres Freund <and...@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.
Thanks! + <para> + Concurrent indexes based on a <literal>PRIMARY KEY</> or an <literal> + EXCLUSION</> constraint need to be dropped with <literal>ALTER TABLE Typo: s/EXCLUSION/EXCLUDE I encountered a segmentation fault when I ran REINDEX CONCURRENTLY. The test case to reproduce the segmentation fault is: 1. Install btree_gist 2. Run btree_gist's regression test (i.e., make installcheck) 3. Log in contrib_regression database after the regression test 4. Execute REINDEX TABLE CONCURRENTLY moneytmp Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers