From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Index corruption with CREATE INDEX CONCURRENTLY |
Date: | 2017-02-06 12:13:46 |
Message-ID: | 20170206121346.if4vwnjhbfttvf4i@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> writes:
> > 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. The way to deal with that without
> looping is to test whether the index set *actually* changed, not whether
> it just might have changed.
Ah, that's a nice and simple way to fix that patch! I see that Pavan
confirmed that it fixes the tests we saw failing too. It seems to me
that we should go with this one, and it looks unlikely that this causes
other problems.
BTW, while neiter Pavan nor I sent this patch to -hackers, this
implementation is pretty much the same thing we did. Pavan deserves
credit as co-author in this commit.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2017-02-06 12:32:28 | Re: Index corruption with CREATE INDEX CONCURRENTLY |
Previous Message | Ruben Buchatskiy | 2017-02-06 11:51:57 | Re: GSoC 2017 |