Re: Support for REINDEX CONCURRENTLY - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Support for REINDEX CONCURRENTLY
Date
Msg-id CAM-w4HN62LU6zf+uATNLi7W5a6EGvb4r7Vy14QxZ2ngrhb4Y9A@mail.gmail.com
Whole thread Raw
In response to Re: Support for REINDEX CONCURRENTLY  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Support for REINDEX CONCURRENTLY  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Oct 4, 2012 at 2:19 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
>> I think what you'd have to do is drop the old index (relying on the
>> assumption that no one is accessing it anymore after a certain point, so
>> you can take exclusive lock on it now) and then rename the new index
>> to have the old index's name.  However, renaming an index without
>> exclusive lock on it still seems a bit risky.  Moreover, what if you
>> crash right after committing the drop of the old index?

I think this would require a new state which is the converse of
indisvalid=f. Right now there's no state the index can be in that
means the index should be ignored for both scans and maintenance but
might have old sessions that might be using it or maintaining it.

I'm a bit puzzled why we're so afraid of swapping the relfilenodes
when that's what the current REINDEX does. It seems flaky to have two
different mechanisms depending on which mode is being used. It seems
more conservative to use the same mechanism and just figure out what's
required to ensure it's safe in both modes. At least there won't be
any bugs from unexpected consequences that aren't locking related if
it's using the same mechanics.

-- 
greg



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Detecting libpq connections improperly shared via fork()
Next
From: Tom Lane
Date:
Subject: Make CREATE AGGREGATE check validity of initcond value?