Bug #22827 repair | error | sort_buffer_size is to small 5.1.11 emt64 repair table
Submitted: 29 Sep 2006 15:13 Modified: 5 Nov 2006 9:08
Reporter: John Spade Email Updates:
Status: No Feedback Impact on me:
Category:MySQL Server Severity:S3 (Non-critical)
Version:Ver 14.12 Distrib 5.1.11-beta, for unkno OS:Linux (RHEL 4.0.4)
Assigned to: CPU Architecture:Any
Tags: large table, repair table, sort_buffer_size

[29 Sep 2006 15:13] John Spade

I was playing around with EMT64 and 5.1.11 ICC binary.  I have tried various sizes of buffers, but on tables over 2GB? I get this error on repair, and on optimize if it requires optimize.  Also, error is english spelling error on 'to' should be 'too'.  I could not find another report of this or in the 5.1.12 fixes.

key_buffer = 4096M
table_cache = 512
sort_buffer_size =64M
read_buffer_size =256M
read_rnd_buffer_size = 256M
myisam_sort_buffer_size = 4096M

mysql> repair table radacct;
| Table          | Op     | Msg_type | Msg_text                                  |
| radius.radacct | repair | error    | sort_buffer_size is to small              | 
| radius.radacct | repair | warning  | Number of rows changed from 0 to 11032003 | 
| radius.radacct | repair | status   | OK                                        | 

-rw-r-----  1 mysql mysql 4250839036 Sep 29 07:58 /var/lib/mysql/radius/radacct.MYD
-rw-r-----  1 mysql mysql  148301824 Sep 29 07:58 /var/lib/mysql/radius/radacct.MYI

How to repeat:
This table is 4GB, but I believe it happens on tables over 2GB.  I have tried on multiple systems.  I tried with key_buffer 2048M and such also.  This system has 16gb ram, but the common factor seems to be table size.  In addition, I cannot set key_buffer larger than 4GB, it ignores it.

Running 'repair table' again on same table yields same errror.  Table seems ok, queries work, etc.  Changing various buffer sizes and such seems to have no effect on the error other than speed.
[29 Sep 2006 15:39] John Spade
appears to be even small tables pulled in from old system, had max data length of 4GB, but expanded with max_rows = 500000000 type command.  Tables natively created in 5.1.11 emt64 with the 6bit pointer seem ok.  Workaround appreciated if someone has.  Thanks

-John Spade
[5 Oct 2006 9:08] Valeriy Kravchuk
Thank you for a problem report. Please, send the results of:

[6 Nov 2006 0:00] Bugs System
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".