Re: bk commit into 4.1 tree (holyfoot:1.2679) BUG#30286

Joro,

First, i sent the new CS about this bug.

> 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 this mean.
The 'inf' return means just that the area is BIG.

> 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) ?

This is exactly what happens in the test. See the problem is that when all keys retrun the 'inf' result, we don't pick any, while the function has to return
a valid key.
The idea of this function is that if we pick the key with minimal 'area increase'
we buld better RTree index. If we have several keys with the 'inf' increase, no matter what one we pick. Sure, they are probably not equal so our RTree index isn't optimal, but we can't count the difference while we use DOUBLE calculations.

Regards
HF

• Original Message ----- From: "Georgi Kodinov" <kgeorge@mysql.com> To: <holyfoot@mysql.com> Cc: <commits@lists.mysql.com> Sent: Monday, August 20, 2007 7:54 PM Subject: Re: bk commit into 4.1 tree (holyfoot:1.2679) BUG#30286

> Hi holyfoot,
>
> 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@mysql.com wrote:
>
>> Below is the list of changes that have just been committed into a local
>> 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@1.2679, 2007-08-17 15:29:47+05:00, holyfoot@mysql.com +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 a double).
> 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 this mean.
>
> 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.
>
> Best Regards,
> Joro
> --
> 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
>
>

-- 
MySQL Code Commits Mailing List
For list archives: 
http://lists.mysql.com/commits
To unsubscribe:    
http://lists.mysql.com/commits?unsub=lists@pantek.com