Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

Поиск
Список
Период
Сортировка
От Pavan Deolasee
Тема Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY
Дата
Msg-id CABOikdMUMv_ZRgiVXwTALPLt7yOX=Pz0gePVDnM0DPRD+RM4CA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY  (Amit Kapila <amit.kapila16@gmail.com>)
Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY  (Pavan Deolasee <pavan.deolasee@gmail.com>)
Список pgsql-hackers
Дерево обсуждения


On Mon, Feb 6, 2017 at 1:44 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:


> 2. In the second patch, we tried to recompute attribute lists if a relcache
> flush happens in between and index list is invalidated. We've seen problems
> with that, especially it getting into an infinite loop with
> CACHE_CLOBBER_ALWAYS. Not clear why it happens, but apparently relcache
> flushes keep happening.

Well, yeah: the point of CLOBBER_CACHE_ALWAYS is to make a relcache flush
happen whenever it possibly could. 

Ah, ok. That explains why the retry logic as originally proposed was causing infinite loop.
 
The way to deal with that without
looping is to test whether the index set *actually* changed, not whether
it just might have changed.

I like this approach. I'll run the patch on a build with CACHE_CLOBBER_ALWAYS, but I'm pretty sure it will be ok. I also like the fact that retry logic is now limited to only when index set changes, which fits in the situation we're dealing with.

Thanks,
Pavan 

--
 Pavan Deolasee                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Possible spelling fixes
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY