On Thu, Mar 7, 2013 at 2:17 AM, Andres Freund <and...@2ndquadrant.com> wrote: >> Indexes: >> "hoge_pkey" PRIMARY KEY, btree (i) >> "hoge_pkey_cct" PRIMARY KEY, btree (i) INVALID >> "hoge_pkey_cct1" PRIMARY KEY, btree (i) INVALID >> "hoge_pkey_cct_cct" PRIMARY KEY, btree (i) > > Huh, why did that go through? It should have errored out?
I'm not sure why. Anyway hoge_pkey_cct_cct should not appear or should be marked as invalid, I think. >> + The recommended recovery method in such cases is to drop the concurrent >> + index and try again to perform <command>REINDEX CONCURRENTLY</>. >> >> If an invalid index depends on the constraint like primary key, "drop >> the concurrent >> index" cannot actually drop the index. In this case, you need to issue >> "alter table >> ... drop constraint ..." to recover the situation. I think this >> informataion should be >> documented. > > I think we just shouldn't set ->isprimary on the temporary indexes. Now > we switch only the relfilenodes and not the whole index, that should be > perfectly fine. Sounds good. But, what about other constraint case like unique constraint? Those other cases also can be resolved by not setting ->isprimary? 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
