Skip site navigation (1) Skip section navigation (2)

Re: Support for REINDEX CONCURRENTLY

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Greg Stark <stark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Subject: Re: Support for REINDEX CONCURRENTLY
Date: 2012-10-03 14:28:59
Message-ID: 4639.1349274539@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> Maybe I am missing something here, but reindex concurrently should do
> 1) BEGIN
> 2) Lock table in share update exlusive
> 3) lock old index
> 3) create new index
> 4) obtain session locks on table, old index, new index
> 5) commit
> 6) process till newindex->insisready (no new locks)
> 7) process till newindex->indisvalid (no new locks)
> 8) process till !oldindex->indisvalid (no new locks)
> 9) process till !oldindex->indisready (no new locks)
> 10) drop all session locks
> 11) lock old index exlusively which should be "invisible" now
> 12) drop old index

You can't drop the session locks until you're done.  Consider somebody
else trying to do a DROP TABLE between steps 10 and 11, for instance.

			regards, tom lane


In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2012-10-03 14:38:57
Subject: Re: [9.1] 2 bugs with extensions
Previous:From: Fabrízio de Royes MelloDate: 2012-10-03 13:11:03
Subject: Re: CREATE SCHEMA IF NOT EXISTS

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group