| 2011-12-08 17:11:26 |
Alexey Kopytov |
bug |
|
|
added bug |
| 2011-12-08 17:11:44 |
Alexey Kopytov |
nominated for series |
|
percona-server/5.1 |
|
| 2011-12-08 17:11:44 |
Alexey Kopytov |
bug task added |
|
percona-server/5.1 |
|
| 2011-12-08 17:11:44 |
Alexey Kopytov |
nominated for series |
|
percona-server/5.5 |
|
| 2011-12-08 17:11:44 |
Alexey Kopytov |
bug task added |
|
percona-server/5.5 |
|
| 2011-12-08 17:11:52 |
Alexey Kopytov |
percona-server/5.1: status |
New |
Confirmed |
|
| 2011-12-08 17:11:54 |
Alexey Kopytov |
percona-server/5.5: status |
New |
Confirmed |
|
| 2011-12-08 17:12:14 |
Alexey Kopytov |
tags |
|
cr i20106 |
|
| 2011-12-08 17:12:29 |
Alexey Kopytov |
percona-server/5.1: assignee |
|
Alexey Kopytov (akopytov) |
|
| 2011-12-08 17:12:32 |
Alexey Kopytov |
percona-server/5.5: assignee |
|
Alexey Kopytov (akopytov) |
|
| 2011-12-08 17:22:55 |
Alexey Kopytov |
percona-server/5.1: status |
Confirmed |
In Progress |
|
| 2011-12-08 17:22:57 |
Alexey Kopytov |
percona-server/5.5: status |
Confirmed |
In Progress |
|
| 2011-12-08 17:33:45 |
Alexey Kopytov |
description |
ALTER TABLE ... IMPORT TABLESPACE is holding the data dictionary mutex during the entire import operation.
This becomes a problem for innodb_expand_import, because that code scans the tablespace being imported, blocking all queries accessing any InnoDB tables during the scan. It does need to protect some data dictionary operations, but it is possible to release the mutex during the most expensive operation, i.e. the .ibd file scan.
The only problem with temporarily releasing the mutex is that changing the table's metadata while it's being imported may lead to data dictionary corruption. But in 5.1 any query trying to open that table will fail with an error, because InnoDB sets the ibd_file_missing file for the in-memory table object until import is complete. In 5.5 queries will block on the metadata lock set by ALTER TABLE. So the table's metadata is protected even without holding the data dictionary mutex. |
ALTER TABLE ... IMPORT TABLESPACE is holding the data dictionary mutex during the entire import operation.
This becomes a problem for innodb_expand_import, because that code scans the tablespace being imported, blocking all queries accessing any InnoDB tables during the scan. It does need to protect some data dictionary operations, but it is possible to release the mutex during the most expensive operation, i.e. the .ibd file scan.
The only problem with temporarily releasing the mutex is that changing the table's metadata while it's being imported may lead to data dictionary corruption. But in 5.1 any query trying to open that table will fail with an error, because InnoDB sets the ibd_file_missing flag for the in-memory table object until import is complete. In 5.5 queries will block on the metadata lock set by ALTER TABLE. So the table's metadata is protected even without holding the data dictionary mutex. |
|
| 2011-12-09 16:56:38 |
Alexey Kopytov |
branch linked |
|
lp:~akopytov/percona-server/bug901775-5.1 |
|
| 2011-12-09 18:38:11 |
Alexey Kopytov |
branch linked |
|
lp:~akopytov/percona-server/bug901775-5.5 |
|
| 2011-12-10 10:45:03 |
Alexey Kopytov |
percona-server/5.1: status |
In Progress |
Fix Committed |
|
| 2011-12-10 10:45:06 |
Alexey Kopytov |
percona-server/5.5: status |
In Progress |
Fix Committed |
|
| 2011-12-16 09:37:20 |
Alexey Kopytov |
percona-server/5.1: milestone |
|
5.1.61-13.2 |
|
| 2011-12-16 09:37:34 |
Alexey Kopytov |
percona-server/5.5: milestone |
|
5.5.19-24.0 |
|
| 2011-12-16 10:04:54 |
Laurynas Biveinis |
percona-server/5.5: milestone |
5.5.19-24.0 |
5.5.18-23.0 |
|
| 2011-12-16 14:27:02 |
Laurynas Biveinis |
percona-server/5.5: status |
Fix Committed |
Fix Released |
|
| 2011-12-28 08:13:44 |
Alexey Kopytov |
branch linked |
|
lp:~akopytov/percona-server/bug901775-5.1 |
|
| 2012-02-07 03:01:28 |
Stewart Smith |
percona-server/5.1: status |
Fix Committed |
Fix Released |
|
