On Tue, Nov 27, 2012 at 9:01 AM, Tom Lane <t...@sss.pgh.pa.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
