On Fri, Mar 8, 2013 at 10:00 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
>
>
> 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.
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
