Alexander Lakhin <exclus...@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