Bug #19138 | The table 'foo' is full displayed on HEAP tables which shouldn't be full | ||
---|---|---|---|
Submitted: | 17 Apr 2006 12:52 | Modified: | 3 May 2007 6:02 |
Reporter: | jocelyn fournier (Silver Quality Contributor) | Email Updates: | |
Status: | Duplicate | Impact on me: | |
Category: | MySQL Server: Memory storage engine | Severity: | S3 (Non-critical) |
Version: | 5.0.20, 5.0.19, 4.1.20 | OS: | Linux (Linux) |
Assigned to: | CPU Architecture: | Any | |
Tags: | qc |
[17 Apr 2006 12:52]
jocelyn fournier
[17 Apr 2006 18:02]
Valeriy Kravchuk
Thank you for a problem report. Please, try to repeat with a newer version, 5.0.20, and inform about the results. Do you have a complete test case according to your description: "Try to insert more than 2000 entries while doing a lot of select and DELETE FROM guest WHERE date<1234." I had inserted random 2074 rows and was not able to repeat the behaviour you described with your insert: mysql> select count(*) from `guest`; +----------+ | count(*) | +----------+ | 2074 | +----------+ 1 row in set (0.00 sec) mysql> INSERT INTO guest (pseudo,date,forum) VALUES -> (INET_ATON('81.49.151.246'),1145276916,1) ON DUPLICATE KEY UPDATE -> date=1145276916,forum=1; Query OK, 1 row affected (0.00 sec) mysql> select version(); +-----------+ | version() | +-----------+ | 5.0.21 | +-----------+ 1 row in set (0.00 sec) Hence the questions above...
[17 Apr 2006 22:35]
jocelyn fournier
Hi, I'll try with 5.0.20. Unfortunately I've no complete testcase yet to reproduce the issue, but I'll do my best to find how to reproduce the issue (note than changing the MAX_ROWS from 10000 to 100000 solves the issue). Regards, Jocelyn
[18 Apr 2006 11:08]
Valeriy Kravchuk
Please, reopen this bug report if you'll find a way to repeat the problem on 5.0.20.
[18 May 2006 23: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".
[21 Jul 2006 9:47]
jocelyn fournier
Hi, The issue just occured again for me with 4.1.20. I've still no real clues on why it occurs. (still time it began to fail with about 1000 entries in the table) Jocelyn
[21 Jul 2006 11:06]
Valeriy Kravchuk
Is it 4.1.20 or 5.0.20? Last time we discussed version 5.0.x. Anyway, please, send the dump of the table when it demonstrates this behaviour to you. Send you my.cnf content also. Can it be just a hardware fault?
[21 Jul 2006 11:11]
jocelyn fournier
Hi, This time is on 4.1.20, and on a different server, so it couldn't be a hardware fault. The dump doesn't help as well : if I reload the dump in a new heap table, the problem doesn't occur. I suspect the issue to be related to some block fragmentation issue (because there is a lot of delete/insert done on this heap table). Jocelyn
[23 Jul 2006 13:42]
Valeriy Kravchuk
Any ideas on how to repeat the behaviour described are still welcomed. Can you send typical "uage profile" for this HEAP table?
[23 Jul 2006 13:56]
jocelyn fournier
Hi, The typical usage : INSERT INTO guest (pseudo,date,forum) VALUES (INET_ATON('$ip_adress'),NOW(),$my_id) ON DUPLICATE KEY UPDATE date=NOW(),forum=$my_id DELETE FROM guest WHERE date < NOW() - INTERVAL 5 minute SELECT SQL_NO_CACHE COUNT(*) FROM guest WHERE forum=$my_id No other queries are used on this table. Those queries are executed each time a page is loaded (and the site has more than 1M pageviews a day) Jocelyn
[3 Aug 2006 14:34]
Valeriy Kravchuk
Please, send your my.cnf content. Try to repeat with a newer versions, 5.0.24 and 4.1.21, just released, and inform about the results.
[3 Sep 2006 23: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".
[3 May 2007 4:29]
Michael K
It's a duplicate of this bug: http://bugs.mysql.com/bug.php?id=18160
[3 May 2007 6:02]
Valeriy Kravchuk
Duplicate of bug #18160, likely.