Re: Support for REINDEX CONCURRENTLY

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: Support for REINDEX CONCURRENTLY
Date: 2013-03-07 16:46:02
Message-ID: 20130307164602.GA17650@alap2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2013-03-07 16:52:39 Re: odd behavior in materialized view
Previous Message Fujii Masao 2013-03-07 16:41:20 Re: Support for REINDEX CONCURRENTLY