On 2013-03-07 09:58:58 +0900, Michael Paquier wrote: > >> > >> + 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? > >> > > > >> > We should stick with the concurrent index being a twin of the index it > >> > rebuilds for consistency. > >> > >> I don't think its legal. We cannot simply have two indexes with > >> 'indisprimary'. Especially not if bot are valid. > >> Also, there will be no pg_constraint row that refers to it which > >> violates very valid expectations that both users and pg may have. > >> > > So what to do with that? > > Mark the concurrent index as valid, then validate it and finally mark it > > as invalid inside the same transaction at phase 4? > > That's moving 2 lines of code... > > > Sorry phase 4 is the swap phase. Validation happens at phase 3.
Why do you want to temporarily mark it as valid? I don't see any requirement that it is set to that during validate_index() (which imo is badly named, but...). I'd just set it to valid in the same transaction that does the swap. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
