From: Georgi Kodinov Date: August 20 2007 3:54pm Subject: Re: bk commit into 4.1 tree (holyfoot:1.2679) BUG#30286 List-Archive: http://lists.mysql.com/commits/32762 Message-Id: MIME-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit 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