Re: Support for REINDEX CONCURRENTLY

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Support for REINDEX CONCURRENTLY
Дата
Msg-id CAM-w4HN62LU6zf+uATNLi7W5a6EGvb4r7Vy14QxZ2ngrhb4Y9A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Support for REINDEX CONCURRENTLY  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: Support for REINDEX CONCURRENTLY
Список 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 по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: Detecting libpq connections improperly shared via fork()
Следующее
От: Tom Lane
Дата:
Сообщение: Make CREATE AGGREGATE check validity of initcond value?