See my remarks below. The fix is generally OK with few requests for
comments and more tests.
On 17.08.2007, at 13:29, holyfoot@stripped wrote:
> Below is the list of changes that have just been committed into a
> 4.1 repository of hf. When hf does a push these changes will
> be propagated to the main repository and, within 24 hours after the
> push, to the public repository.
> For information on how to access the public repository
> see http://dev.mysql.com/doc/mysql/en/installing-source-tree.html
> ChangeSet@stripped, 2007-08-17 15:29:47+05:00, holyfoot@stripped +3 -0
> Bug #30286 spatial index cause corruption and server crash!
> Sometimes the result of the DOUBLE claculations can be bigger
> than DBL_MAX constant we use in code. If that happens in
> rtree_pick_key it can fail as it cannot find suitable key.
> So we shouldn't use DBL_MAX constant as a biggest double we
> can ever get.
I don't think a valid double value can be greater than DBL_MAX
(except +/-INF and NaN). Here we may have a NaN because of the way a
key is selected : it tries to calculate the MBR area increase caused
by adding the new polygon to the key (an operation that may overflow
So as a result rtree_area_increase() returns NaN (and inf for its
output parameter "ab_area"). And this is the key it doesn't find.
I suggest that you add a (very verbose) comment to rtree_area_increase
() that explains why and when it can return NaN+inf and what does
Then please think about (and ideally add a test) what can happen if
the first two keys on the page will trigger NaN+inf case for the same
value added to them. Can there be such ? If yes, how does NaN compare
to a NaN (i.e. which key to choose) ?
Obviously the commit comment needs rephrasing as well.
Other than that I don't see other problems with the fix.
Georgi Kodinov, Senior Software Engineer
MySQL AB, Plovdiv, Bulgaria, www.mysql.com
Office: +359 32 634 397 Mobile: +359 887 700 566 Skype: georgekodinov
Are you MySQL certified? www.mysql.com/certification