Re: Support for REINDEX CONCURRENTLY

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: Support for REINDEX CONCURRENTLY
Дата
Msg-id 50734C5A.7020209@nasby.net
обсуждение исходный текст
Ответ на Re: Support for REINDEX CONCURRENTLY  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: Support for REINDEX CONCURRENTLY
Re: Support for REINDEX CONCURRENTLY
Список pgsql-hackers
On 10/5/12 9:57 PM, Michael Paquier wrote:
> In the current version of the patch, at the beginning of process a new index is created. It is a twin of the index it
hasto replace, meaning that it copies the dependencies of old index and creates twin entries of the old index even in
pg_dependand pg_constraint also if necessary. So the old index and the new index have exactly the same data in catalog,
theyare completely decoupled, and you do not need to worry about the OID replacements and the visibility consequences.
 

Yeah, what's the risk to renaming an index during concurrent access? The only thing I can think of is an "old" backend
referringto the wrong index name in an elog. That's certainly not great, but could possibly be dealt with.
 

Are there any other things that are directly tied to the name of an index (or of any object for that matter)?
-- 
Jim C. Nasby, Database Architect                   jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: MemSetLoop ignoring the 'val' parameter
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Support for REINDEX CONCURRENTLY