Alexander Lakhin <exclusion@gmail.com> writes:
> (Unfortunately for me) I found no anomalies related to gbt_text_same()
> with an index created with the previous implementation. I've added
> diagnostic logging that shows when gbt_text_same() returns 0 for keys
> that are the equal but have different padding. So I've observed that
> gbt_text_same() returns incorrect result, but all the btree_gist tests
> still pass. Moreover, unconditional "*result = 0;" in gbt_text_same()
> doesn't affect the tests at all.
> I've found that gbt_text_same() is called by gistKeyIsEQ() from
> backend/access/gist/gistutil.c, and made gistKeyIsEQ() return false any
> time. And even with such change all check-world tests still pass (except
> for isolation/predicate-gist that failed due to locking of pages split
> differently). So for now, I still don't know how to get incorrect query
> results due to incorrect gistKeyIsEQ() behavior/excessive page splitting.
Yeah, if that's the only use-case then it's pretty easy to see that
an overly strict equality test isn't going to hurt us much. At worst
it'll cause the index to be a little bit inefficiently stored due to
unnecessary node splits. Even then, that won't happen much in normal
use, since the discrepancy could only arise once in the lifespan of
an index node (when it first sees a new-style entry that could have
been considered equal to the old-style value).
So I think this solution will work, and I'll go ahead and push it.
Thanks for testing! (and for the original report ...)
regards, tom lane