List:Commits« Previous MessageNext Message »
From:Alexey Kopytov Date:September 6 2007 2:38pm
Subject:Re: bk commit into 5.1 tree (kaa:1.2436) BUG#5731
View as plain text  
Hi Serg,

On Thursday 06 September 2007, Sergei Golubchik wrote:
>Hi!
>
>On Jul 17, Alexey Kopytov wrote:
>> ChangeSet@stripped, 2007-07-17 20:13:28+04:00, kaa@stripped +2 -0
>>   This patch is a part of work on bug #5731 "key_buffer_size not properly
>> restricted to 4GB".
>>
>>   The patch limits read_buffer_size and read_rnd_buffer_size by 2 GB on
>> all platforms for the following reasons:
>>
>>   - I/O code in mysys, code in mf_iocache.c and in some storage
>>   engines do not currently work with sizes > 2 GB for those buffers
>>   - even if the above had been fixed, Windows POSIX read() and write()
>>   calls are not 2GB-safe, so setting those buffer to sizes > 2GB would
>>   not work correctly on 64-bit Windows.
>>
>>   include/my_global.h@stripped, 2007-07-17 20:13:24+04:00, kaa@stripped +0
>> -3 Removed SSIZE_MAX because it's not neeeded anymore.
>>
>>   sql/mysqld.cc@stripped, 2007-07-17 20:13:24+04:00, kaa@stripped +3 -3
>>     Limit read_buffer_size and read_rnd_buffer_size by 2 GB on all
>> platforms.
>>
>> --- 1.619/sql/mysqld.cc	2007-02-14 16:51:46 +03:00
>> +++ 1.620/sql/mysqld.cc	2007-07-17 20:13:24 +04:00
>> @@ -6195,7 +6195,7 @@ The minimum value for this variable is 4
>>     (gptr*) &global_system_variables.read_buff_size,
>>     (gptr*) &max_system_variables.read_buff_size,0, GET_ULONG,
>> REQUIRED_ARG, -   128*1024L, IO_SIZE*2+MALLOC_OVERHEAD, SSIZE_MAX,
>> MALLOC_OVERHEAD, IO_SIZE, +   128*1024L, IO_SIZE*2+MALLOC_OVERHEAD,
>> INT_MAX, MALLOC_OVERHEAD, IO_SIZE,
>
>Wouldn't INT32_MAX be safer ?
>

Hm, practically either way is equally safe, unless there is a supported  by us  
platform where sizeof(int) != sizeof(int32). I am not aware of any such 
platform.

Theoretically, the right constant depends on what data type is used in the 
code. If the code uses int32 which we hardcode to be 32-bit, then INT_MAX32 
would be the right choice. If the code uses the platform 'int' type, then 
using platform-provided constant INT_MAX looks more 'logical' to me. The code 
in mf_iocache.c and my_{read,write}.c uses the 'native' int/uint types, not 
the hardcoded ones, hence INT_MAX. The Windows POSIX API also defines 
read()/write() to return int. What do you think?

Best regards,

-- 
Alexey Kopytov, Software Developer
MySQL AB, www.mysql.com

Are you MySQL certified?  www.mysql.com/certification
Thread
bk commit into 5.1 tree (kaa:1.2436) BUG#5731Alexey Kopytov17 Jul
  • Re: bk commit into 5.1 tree (kaa:1.2436) BUG#5731Sergei Golubchik6 Sep
    • Re: bk commit into 5.1 tree (kaa:1.2436) BUG#5731Alexey Kopytov6 Sep
      • Re: bk commit into 5.1 tree (kaa:1.2436) BUG#5731Sergei Golubchik6 Sep