<br /><br /><div class="gmail_quote">On Fri, Feb 26, 2010 at 12:36 AM, Gokulakannan Somasundaram <span dir="ltr"><<a
href="mailto:gokul007@gmail.com">gokul007@gmail.com</a>></span>wrote:<br /><blockquote class="gmail_quote"
style="border-left:1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><div
class="gmail_quote"><blockquoteclass="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt
0pt0.8ex; padding-left: 1ex;"> To be a bit more concrete: the typical sort of failure that you could<br /> get from
brokenbtree operators is failure of transitivity, that is<br /> the comparators report A < B and B < C for some
A,B, C, but do not say<br /> that A < C when those two values are compared directly. I don't see any<br />
convenientway to detect that as a byproduct of normal index operations,<br /> because you wouldn't typically have a
reasonto make all three<br /> comparisons in close proximity. Indeed, the searching and sorting<br /> algorithms do
theirbest to avoid making "redundant" comparisons of that<br /> kind.<br /></blockquote></div><br /></div>This is
interestingTom, but i am unable to understand, why it won't affect the current indexes. While insertion it might get
insertedin a block and offset, and while searching it might either return no results / show a wrong place. Because
orderingis required for searching also right? I definitely feel, i am missing something here.<br
/></blockquote></div><br/>It definitely affects current indexes. We can't completely avoid bad user functions. That is
whyit is important to put limits on how much damage they can do. That's the motivation for the idea I mentioned before,
ofdouble-checking visibility data in an IndexTuple before letting it survive a VACUUM. <br />