MySQL Bugs: #55008: "Fetching...." on tables

Bug #55008	"Fetching...." on tables
Submitted:	5 Jul 2010 17:47	Modified:	10 Aug 2010 12:32
Reporter:	Daniel Ennis	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Workbench: SQL Editor	Severity:	S2 (Serious)
Version:	5.2.25 CE	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	can not use, Fetching

Description:
After creating a new Schema/DB, Trying to open it (double click) as to select as current database, MySQL Benchmark shows "fetching..." beside the Schema name, and spawns 3 child nodes that all say "fetching..." also.

It stays this way for over 10 minutes and never stops.
Closing connection and reconnecting did not help.

Closing application and reconnecting did not help.

I was able to right click a "fetching..." node and Create a new Table, and it was successful as I can see it in other DB viewers such as phpMyAdmin, however the Workbench still will not show it and stays on fetching...

Overview shows 0 tables under my database when there is 1.

I am able to see tables on the Default schema it appears.

Connection type incase it matters:
Standard TCP/IP Over SSH Using Public Key authentication

MySQL Server version:
mysql  Ver 14.14 Distrib 5.1.43, for redhat-linux-gnu (x86_64) using readline 5.1

How to repeat:
Try to double click any database that is not the default.
see "fetching..."

Thank you for the bug report. Which exactly version are you using 5.2.25?. Thanks in advance.

5.2.25 CE just downloaded today.

Please, try to connect to the same database with mysql command line client and upload the results of:

show table status;

from it.

mysql> show table status;
| Name       | Engine | Version | Row_format | Rows | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Create_time         | Update_time         | Check_time | Collation       | Checksum | Create_options                | Comm
ent |

| users_auth | MyISAM |      10 | Dynamic    |    0 |              0 |           0 | 281474976710655 |         4096 |         0 |              1 | 2010-07-05 18:29:36 | 2010-07-05 18:29:36 | NULL       | utf8_general_ci |     NULL | pack_keys=1 delay_key_write=1 |     

1 row in set (0.00 sec)

like I said it works fine on the "default schema for this connection"

If i set the DB i want to use as default and reconnect itll work, i just cant SWITCH DB's from the default

It's like its forgetting to do the USE db; command

Do you use a special sql-mode on server?

We need to get last commands from general log file from you.

We need to know the command which occurs hanging.

I'm not going to be able to do that. I have tons of queries running every second on my DB :/

and no im not using anything special. just standard MySQL Server with one of the default my.cnf templates for bigger cache use.

Confirmed it also happens on Windows XP SP3

heres [mysqld] config in my.cnf

[mysqld]
bind-address=127.0.0.1
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
#old_passwords=1
skip-locking
key_buffer = 512M
max_allowed_packet = 1M
table_cache = 512
sort_buffer_size = 4M
read_buffer_size = 4M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size= 32M
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 8

I have the exact same problem.  Happens on Win 7 x64 and OSX.  It makes the Workbench semi-useless.

See bug #55356

I can confirm the same behavior on Mac OS 10.6.3, exact same description. Three fetching.... threads open, tables are not fetched.

As suggested here, for the first schema everything is ok, the three threads open Tables, Views and Routines subitems, all fine. For the 2nd schema onwards, no luck. Sub-items work ok on the first table as well.

Suspicious messages on log is just a single message upon startup, don't know if related.

100723  9:16:20 [ERROR] Column count of mysql.proc is wrong. Expected 20, found 16. The table is probably corrupted

Version: '5.1.46-log'

I hope this helps.

The error message shows that you once upgraded from MySQL 5.0 to MySQL 5.1 but you forgot
to run mysql_upgrade.

Please try this first. Run mysql_upgrade.

See also bug #55356

Ok confirming doing mysql_upgrade fixed the problem, but i still think something needs to be fixed on MySQL workbench about this...

Why does everything else such as other tools and apps that use the DB still work fine? Why does ONLY MySQL workbench blow up on a DB that hasn't ran mysql_upgrade?

At the very least MySQL Workbench should check if the queries are failing due to this and alert the user they may need to run mysql_upgrade.

Many thanks for your feedback.

I will close this bug report now.

Not upgrade from one main version (e.g. 5.0) to a higher version (e.g. 5.1) correct ... yes, it will work for the first time but then it will behave very odd.

We added some new features in 5.1 and needed to re-structure mysql database.
Also we fixed bugs in collations so that indexes won't work.

The tool mysql_upgrade will restructure your schemas to the new structure of mysql database also it will re-index your tables and so on.

I can confirm that mysql_upgrade also fixed the same problem for me in Fedora 16 with MySQL Workbench 5.2.37 rev 8576 after importing a database backup from another server.

Upgrade command also worked for me on Mountain Lion running MWB 5.2.42.