Bug #79460 After upgrading from 5.5 to 5.6, Workbench now freezes on larger result sets
Submitted: 30 Nov 2015 16:46 Modified: 22 Nov 2016 1:15
Reporter: Brian Hambleton Email Updates:
Status: No Feedback Impact on me:
None 
Category:MySQL Workbench: SQL Editor Severity:S2 (Serious)
Version:6.3.5 OS:Windows (Microsoft Windows 8.1 Pro)
Assigned to: CPU Architecture:Any
Tags: WBBugReporter

[30 Nov 2015 16:46] Brian Hambleton
Description:
After upgrading the database server from 5.5 to 5.6, Workbench now freezes when when attempting to display larger amounts of data. Before upgrading the database server to 5.6.27, this was not an issue and the data was being displayed within milliseconds (as expected).

I do not have an exact size of the returned data which will cause an issue. Small amounts of data are still returned without issue but at some point once you increase the data that is being returned, the issue just happens without warning.

An example: A table that has 11 columns and an average row length of 167. Limiting the returned query results to 1185 rows works without issue (as expected). However just slightly increasing that number to 1190, causes Workbench to freeze (and never come back). I've waited over half an hour for Workbench to come back before killing the process (cancelling the query does not work).

In regards to tables with large amounts of data per row (MEDIUMTEXT fields), I can't even return a single row. This was not an issue before the upgrade and was taking just milliseconds to execute before.

This issue is occurring for multiple users at my organization, not just myself. I also tried different versions of Workbench but all seem to have the issue. It does not cause Workbench to crash, just freeze (does not prompt me to fill out a bug report either, so it seems like Workbench itself is not aware that something has happened). It is acting like it is waiting for some process to return. I have to kill the Workbench process in the task manager. I don't see any errors in the error logs. Other MYSQL clients do not experience this issue after the upgrade, so I'm guessing that this is just to do with Workbench. 

I should also mention that I am connecting to the MySQL database using SSH. Database version is 5.6.27-0ubuntu0.14.04.1-log (Ubuntu).

Thanks!

How to repeat:
Upgrade an existing database from 5.5 to 5.6, then run query that produces a larger (in size) result set.
[5 Jan 2016 21:01] MySQL Verification Team
Looks like duplicate/related with http://bugs.mysql.com/bug.php?id=79329. Please check.
[6 Jan 2016 14:55] Brian Hambleton
The issue sounds similar, however I'm not sure I would say it is duplicate. We had an existing database and did not experience this issue when the database server was version 5.5. Only after upgrading from 5.5 to 5.6 did it become an issue. We are also connecting to remote MySQL instances - not local.

I listed it as a Workbench issue because other clients do not experience the issue. Also, from what I can tell, the database seems to be querying and returning the data to Workbench without issue. It seems 100% on Workbench's end but was not a problem with version 5.5 for some reason.

Unfortunately, this issue has prevented us from using Workbench for our MySQL client. We've had to switch to another because we did not want to down grade our MySQL instances. We would like to switch back to Workbench once this is resolved. Thanks.
[20 Apr 2016 15:17] Boaz Yahav
This problem is definitely around and i see many with this problem.
I have two servers, one with MySQL 5.5.43 and one with 5.6.29.
I work with different mysql workbench  versions and there is no problem working with MySQL 5.5.43. When working with 5.6.29 and SELECTING with LIMIT over 500 workbench hangs...
[20 Apr 2016 15:18] Boaz Yahav
+subscribe
[22 Oct 2016 1:15] MySQL Verification Team
Please try version 6.3.8. Thanks.
[23 Nov 2016 1: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".