On Thu, Feb 25, 2010 at 3:59 PM, Gokulakannan Somasundaram < gokul...@gmail.com> wrote:
> I disagree with that, Gokul -- if the ordering operators are volatile or >> just incorrect, during DELETE, you could set xmax in the wrong IndexTuple. >> Then there will be another IndexTuple that says it's visible, but it points >> to a non-visible heap tuple. I think you should follow the pointers to the >> heap before you decide to let an index tuple remain in the index during >> vacuum. This would ensure that all references from an index to a heap tuple >> are removed before vacuuming the heap tuple. I would be worried about what >> might break if this invariant doesn't hold. >> > > Well, Karl, if we have to support function based indexes/IOT, one thing is > for sure. We can't support them for volatile functions / broken data types. > Everyone agrees with that. But the question is how we identify something is > not a volatile function. Only way currently is to let the user make the > decision( Or we should consult some mathematician ). So we need not consult > the heaptuple. > > First of all, volatility is not the only issue. The ordering ops could also be incorrect, e.g., violate the transitivity property. there is no reliable way to determine if a function is volatile and/or incorrectly specified. Of course, PG can't "support" indexing with incorrect functions. However, it's worthwhile to guard against too much damage being done if the user's function has a bug. Maybe I'm wrong? Maybe an index tuple with a dangling pointer is actually harmless? Karl
