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: | |
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
[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?