List:Commits« Previous MessageNext Message »
From:Alexey Botchkov Date:August 30 2007 12:58pm
Subject:Re: bk commit into 4.1 tree (holyfoot:1.2679) BUG#30286
View as plain text  
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@stripped>
To: <holyfoot@stripped>
Cc: <commits@stripped>
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@stripped 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@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  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
>
> 

Thread
bk commit into 4.1 tree (holyfoot:1.2679) BUG#30286holyfoot17 Aug
  • Re: bk commit into 4.1 tree (holyfoot:1.2679) BUG#30286Georgi Kodinov20 Aug
  • Re: bk commit into 4.1 tree (holyfoot:1.2679) BUG#30286Alexey Botchkov30 Aug