| Bug #14155 | MAX_ROWS is wrong on 64bit platform | ||
|---|---|---|---|
| Submitted: | 19 Oct 2005 22:19 | Modified: | 9 Dec 2005 0:18 |
| Reporter: | Peter Zaitsev (Basic Quality Contributor) | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: MyISAM storage engine | Severity: | S3 (Non-critical) |
| Version: | 4.1.14, 5.0.13-rc | OS: | Linux (Linux 64bit) |
| Assigned to: | Jim Winstead | CPU Architecture: | Any |
[19 Oct 2005 22:19]
Peter Zaitsev
[20 Oct 2005 5:52]
Valeriy Kravchuk
Verified on our nocona server with 4.1.14: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 1 to server version: 4.1.14 Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> create table tmp(i int) max_rows=100000000000; Query OK, 0 rows affected (0.02 sec) mysql> show create table tmp; +-------+----------------------------------------------------------------------------------------------------------+ | Table | Create Table | +-------+----------------------------------------------------------------------------------------------------------+ | tmp | CREATE TABLE `tmp` ( `i` int(11) default NULL ) ENGINE=MyISAM DEFAULT CHARSET=utf8 MAX_ROWS=1215752192 | +-------+----------------------------------------------------------------------------------------------------------+ 1 row in set (0.01 sec) mysql> exit Bye -bash-2.05b$ uname -a Linux nocona.mysql.com 2.4.21-32.0.1.ELsmp #1 SMP Tue May 17 17:46:36 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux The same result was obtained with 5.0.13-rc on nocona.
[27 Oct 2005 0:38]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/internals/31535
[9 Nov 2005 20:05]
Barkley Vowk
Please also fix setting the max_rows in alter table, as the supplied patch only addresses max_rows on creation. If the program attempts to tweak max_rows of an existing database, its wrapped at 2^32-1 again.
[9 Nov 2005 22:39]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/internals/32122
[24 Nov 2005 1:01]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/internals/32629
[29 Nov 2005 19:37]
Jim Winstead
Fixed in 5.0.17 and 5.1.4.
[9 Dec 2005 0:18]
Paul DuBois
Noted in 5.0.17, 5.1.4 changelogs.
[19 Aug 2008 3:24]
Golden Liu
I've noticed that in the following patch, you made this change: - if (create_info->max_rows > ~(ulong) 0) - create_info->max_rows= ~(ulong) 0; - if (create_info->min_rows > ~(ulong) 0) - create_info->min_rows= ~(ulong) 0; + if (create_info->max_rows > UINT_MAX32) + create_info->max_rows= UINT_MAX32; + if (create_info->min_rows > UINT_MAX32) + create_info->min_rows= UINT_MAX32; (the pack is here: http://lists.mysql.com/internals/32629) So I still can't set MAX_ROWS bigger than UINT_MAX32, even in a 64-bit system. Why? If I just change the patch to something like this: - if (create_info->max_rows > ~(ulong) 0) - create_info->max_rows= ~(ulong) 0; - if (create_info->min_rows > ~(ulong) 0) - create_info->min_rows= ~(ulong) 0; + if (create_info->max_rows > UINT_MAX64) + create_info->max_rows= UINT_MAX64; + if (create_info->min_rows > UINT_MAX64) + create_info->min_rows= UINT_MAX64; Does this fix this bug so we can set MAX_ROWS bigger than UINT_MAX32? 3x.
