Re: Re: Problem Observed in behavior of Create Index Concurrently and Hot Update

On Tue, Nov 27, 2012 at 9:01 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> I wrote:
>
> Either state of indcheckxmin is valid with all three of these
> combinations, so the specific kluge I was contemplating above doesn't
> work. But there is no valid reason for an index to be in this state:
>
> indisvalid = true, indisready = false
>
> I suggest that to fix this for 9.2, we could abuse these flags by
> defining that combination as meaning "ignore this index completely",
> and having DROP INDEX CONCURRENTLY set this state during its final
> wait before removing the index.
>
>
Yeah, this looks much better, given our inability to add a new catalog
column in 9.2. Can we cheat a little though and use a value other than 0
and 1 for indisvalid or indisready to tell the server to interpret it
differently ? I would assume not, but can't see a reason unless these
values are converted to other types and back to boolean.

Andres complained about the fact that many callers of RelationGetIndexList
are probably not ready to process invalid or not-yet-ready indexes and
suggested that those changes should be backpatched to even older releases.
But IMO we should do that with a test case that demonstrates that there is
indeed a bug. Also, we should teach RelationGetIndexList to take a flags
argument and filter out indexes that the caller is not interested instead
of every caller doing the checks separately.

Thanks,
Pavan