Horton
Menu

Re: Support for REINDEX CONCURRENTLY

Andres Freund <andres@2ndquadrant.com>

View thread
From: Andres Freund <andres@2ndquadrant.com>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: Fujii Masao <masao.fujii@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>, Simon Riggs <simon@2ndquadrant.com>
Date: 2013-03-07T16:46:02Z
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

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Background worker processes

  2. Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.

  3. Work around unportable behavior of malloc(0) and realloc(NULL, 0).

  4. Properly set relpersistence for fake relcache entries.