>>>>> "Teodor" == Teodor Sigaev <teo...@sigaev.ru> writes:
>> even further. And what confidence do you have that this change >> eliminates all forms of the problem, anyway? Teodor> Yes, I think. Because that part of code ( if (IS_BADRATIO) Teodor> {...} ) is a corner case itself. In example from Andrew, all Teodor> boxes are placed to one page because of floating-point Teodor> rounding. Yes, it's a corner case, but it arose in real-world data (the test data set is contrived, but that's simply because it was the easiest way to demonstrate the bug without access to the real data, which had a much larger variation in box sizes). Teodor> We could check IS_BADRATIO again and if it's just put one Teodor> half of all boxes on one page and another half to the another Teodor> page as it does if all boxes are equal. But FPeq() seemed to Teodor> me a simpler solution and FP* comparisons are widely used in Teodor> geometry. I think that not only does there need to be another IS_BADRATIO check, but also there needs to be some sort of backstop in gistSplit or gistUserPicksplit to either recover or (as a last resort) error out cleanly rather than crash the entire db in cases that would result in infinite recursion. -- Andrew (irc:RhodiumToad) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers