>>>>> "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

Reply via email to