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
Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY |
| Список | 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
PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: