On Thu, Oct 4, 2012 at 2:19 AM, Michael Paquier <michael.paqu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
