Bug #72321 MySQL Workbench crash when data migrate from PostgreSQL 9.3
Submitted: 11 Apr 2014 23:50 Modified: 12 Mar 2016 9:28
Reporter: Yaning Zhu Email Updates:
Status: No Feedback Impact on me:
None 
Category:MySQL Workbench: Migration Severity:S3 (Non-critical)
Version:6.1.4, maybe all versions prior OS:Windows
Assigned to: CPU Architecture:Any
Tags: migration, Postgresql

[11 Apr 2014 23:50] Yaning Zhu
Description:
When migrating from a PostgreSQL 9.3 instance, Workbench will hard crash on Windows on the "Migration" screen.

Running with -log-level=debug3 doesn't tell us much:

16:39:57 [DB1][         Wizard]: Starting...Adding new timeout
16:39:57 [DB1][ mforms managed]: Creating new TimerHandler
16:39:57 [DB1][         Wizard]: Migrate Selected Objects....Starting thread for 'Migrate Selected Objects'
16:39:57 [DB1][         Wizard]: Migrate Selected Objects finishedRunning slot on main thread (not waiting for it)
16:39:57 [DB2][ mforms managed]: Cross thread invocation required
16:39:57 [DB2][ mforms managed]: Running cancel_slot on main thread
16:39:57 [DB1][         Wizard]: Generate SQL CREATE Statements....Starting thread for 'Generate SQL CREATE Statements'

You can see two errors in the Application log in Event Viewer.

Error 1026: .NET Runtime error:
Application: MySQLWorkbench.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: exception code c0000005, exception address 05D53FF5

Error 1000: Application Error
Faulting application name: MySQLWorkbench.exe, version: 6.1.4.11773, time stamp: 0x5332fe5f
Faulting module name: grt.dll, version: 0.0.0.0, time stamp: 0x5332f740
Exception code: 0xc0000005
Fault offset: 0x00003ff5
Faulting process id: 0xb44
Faulting application start time: 0x01cf55dcda134493
Faulting application path: C:\Program Files (x86)\MySQL\MySQL Workbench 6.1 CE\MySQLWorkbench.exe
Faulting module path: C:\Program Files (x86)\MySQL\MySQL Workbench 6.1 CE\grt.dll

How to repeat:
Install Postgres ODBC 32bit drivers, define a System DSN to a Postgres 9.3 database. I just launched a Heroku instance. Connection test should be successful. Note that I was forced to flip the SSL switch because all Heroku Postgres instances require SSL.

Open MySQL Workbench > Data Migration

On "Source Selection" screen, Choose PostgreSQL and Connection Method: ODBC Data Source. Select the DSN that you just created.

On "Target Selection" screen, select any MySQL database. I just chose one that I had running, 5.6. A standard TCP/IP connection, didn't bother setting up ODBC for it.

You should be able to flip through the next few screens by accepting default settings.

When you get to the "Migration" screen, `Migrate Selected Objects` will succeed, but `Generate SQL CREATE Statements` will cause MySQL Workbench to crash. Windows will tell you that MySQL Workbench has stopped working.
[15 Apr 2014 16:20] Alfredo Kojima
Does that happen with any source DB? Can you try with something else? If it only happens with your specific DB, is it possible to upload a dump of the schema (no data) so we can try repeating it?
[15 Apr 2014 21:31] Yaning Zhu
After trying over all my available PG databases, figuring out what works and what doesn't, I discovered that all the databases that Workbench crashes on have a common view. Whether it's created by PG by default or Heroku I don't know.

------------------------------------------------------------
CREATE OR REPLACE VIEW pg_stat_statements AS 
 SELECT pg_stat_statements.userid,
    pg_stat_statements.dbid,
    pg_stat_statements.query,
    pg_stat_statements.calls,
    pg_stat_statements.total_time,
    pg_stat_statements.rows,
    pg_stat_statements.shared_blks_hit,
    pg_stat_statements.shared_blks_read,
    pg_stat_statements.shared_blks_dirtied,
    pg_stat_statements.shared_blks_written,
    pg_stat_statements.local_blks_hit,
    pg_stat_statements.local_blks_read,
    pg_stat_statements.local_blks_dirtied,
    pg_stat_statements.local_blks_written,
    pg_stat_statements.temp_blks_read,
    pg_stat_statements.temp_blks_written,
    pg_stat_statements.blk_read_time,
    pg_stat_statements.blk_write_time
   FROM pg_stat_statements() pg_stat_statements(userid, dbid, query, calls, total_time, rows, shared_blks_hit, shared_blks_read, shared_blks_dirtied, shared_blks_written, local_blks_hit, local_blks_read, local_blks_dirtied, local_blks_written, temp_blks_read, temp_blks_written, blk_read_time, blk_write_time);

ALTER TABLE pg_stat_statements
  OWNER TO postgres;
GRANT ALL ON TABLE pg_stat_statements TO postgres;
GRANT SELECT ON TABLE pg_stat_statements TO public;
-----------------------------------------------------------------

The view is depended on this function:

CREATE OR REPLACE FUNCTION pg_stat_statements(OUT userid oid, OUT dbid oid, OUT query text, OUT calls bigint, OUT total_time double precision, OUT rows bigint, OUT shared_blks_hit bigint, OUT shared_blks_read bigint, OUT shared_blks_dirtied bigint, OUT shared_blks_written bigint, OUT local_blks_hit bigint, OUT local_blks_read bigint, OUT local_blks_dirtied bigint, OUT local_blks_written bigint, OUT temp_blks_read bigint, OUT temp_blks_written bigint, OUT blk_read_time double precision, OUT blk_write_time double precision)
  RETURNS SETOF record AS
'$libdir/pg_stat_statements', 'pg_stat_statements'
  LANGUAGE c VOLATILE
  COST 1
  ROWS 1000;
ALTER FUNCTION pg_stat_statements()
  OWNER TO postgres;
----------------------------------------------------------

Note that while my user is able to grab the CREATE statement for the view and the function, my user does not have the permission to create the function due to how Heroku sets up permission (ERROR:  permission denied for language c).

Does the migration process try to create functions and views too?
[28 Apr 2014 17:18] Milosz Bodzek
Serialize objects from target catalog

Attachment: migration_object_migration.py (text/x-python), 4.68 KiB.

[28 Apr 2014 17:25] Milosz Bodzek
Thank you for your bug report Yaning Zhu. Could you replace file <WB dir>/plugins/migration/frontend/migration_object_migration.py with attached file, and then run migration wizard once again, please. After that, you'll find new genearted file with serialized objects of target catalog at: /tmp/dump.xml. Please, send it to us. This will help us to solve the problem and create a patch.
[20 May 2014 15:39] Milosz Bodzek
Edit that file, please. Somewhere around line 117 you will find the line:
grt.serialize (self.main.plan.targetCatalog,'/tmp/dump.xml')
change the path to a valid and then save the file. After that run migration wizard once again and send generated file to us.
[28 May 2014 0:27] Yaning Zhu
File added.
[28 May 2014 9:58] Sergio Soto
I'm trying to export from M SQL Server to MySQL with MySQL Workbench 6.1.6.11834

Workbench crash after configure source and target. The crash report:
Problem signature:
  Problem Event Name:	APPCRASH
  Application Name:	MySQLWorkbench.exe
  Application Version:	6.1.6.11834
  Application Timestamp:	53729aea
  Fault Module Name:	grt.dll
  Fault Module Version:	0.0.0.0
  Fault Module Timestamp:	537293fe
  Exception Code:	c0000005
  Exception Offset:	00003ff5
  OS Version:	6.1.7601.2.1.0.256.1
  Locale ID:	3082
  Additional Information 1:	0a9e
  Additional Information 2:	0a9e372d3b4ad19135b953a78882e789
  Additional Information 3:	0a9e
  Additional Information 4:	0a9e372d3b4ad19135b953a78882e789

I found that thread. I have changed migration_object_migration.py file. Now the workbench doesn't crash, but give that error:

Starting...
Migrate Selected Objects....
- Migrating...
- Migrating schema ----------...
- Migrating schema contents for schema ORION_NPM
- Table ---------- migrated
- Table ---------- migrated
- Table ---------- migrated
- Table ---------- migrated
- View ---------- migrated
- Finalizing foreign key migration...
- Migration finished
Migrate Selected Objects finished
Generate SQL CREATE Statements....

Traceback (most recent call last):
  File "C:\Program Files\MySQL\MySQL Workbench 6.1 CE\workbench\wizard_progress_page_widget.py", line 192, in thread_work
    self.func()
  File "C:\Program Files\MySQL\MySQL Workbench 6.1 CE\modules\migration_object_migration.py", line 117, in task_generate_sql
    grt.serialize(self.main.plan.targetCatalog, '/tmp/dump.xml')
SystemError: serializing object: Could not save XML data to file /tmp/dump.xml
ERROR: Generate SQL CREATE Statements: serializing object: Could not save XML data to file /tmp/dump.xml
Failed

More information about. I reproduce the crash only with that database. I tried to export other and the problem doesn't appear.

Do you need more info?
[28 May 2014 10:19] Sergio Soto
The error was caused because I'm in Windows, so /tmp/ folder doesn't exist. I change the path to C:\Windows\Temp\dump.xml

Then, the dump.xml is created but the crass happens again.

How can I use the dump.xml?
[28 May 2014 11:55] Milosz Bodzek
Thank you Yaning Zhu.

Sergio Soto: you cant't use this patch to fix that bug. This is just to generate a file dump.xml that will help us analyze the problem and fix the bug. So just upload your generated dump.xml file here.
[28 May 2014 11:56] Sergio Soto
dumped db with .py

Attachment: dump.xml (text/xml), 274.22 KiB.

[20 Jun 2014 5:02] supun aa
i also face that issue ,pls fix thia bug ASAP

OS: windows server 2012
 Application Name:	MySQLWorkbench.exe
  Application Version:	6.1.6.11834
[3 Sep 2014 16:45] Milosz Bodzek
Thank you for your help, unfortunately i can't repeat that issue. 
So, can someone send me dump of PostgreSQL schema that will being migrated? You can send me directly on e-mail if you don't want be a public.
[13 Mar 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".
[23 Jul 2019 4:06] Chaitanya Birudavolu
I'm stuck on the same problem. I'm using MySQL Workbench version 8.0, and PostGreSQL version 10. Everything is on my localhost, which is a Win10 laptop. Wbench crashes, and the final log file entry is the same as already reported in this bug. Please could you let me know what additional info is required from me to proceed to work on this defect.
[7 Dec 2019 22:26] Tobias Peltzer
Hello,
I'am also encountering the same problem. How can I fix this?
[20 Jan 2023 6:26] Kah CHoon Ng
Hi, experiencing the same problem in 2023, any solution or workaround on this?