lp://staging/~percona-dev/percona-server/5.1.56-expand_pass_corrupt_table

Branch merges

Propose for merging

No branches dependent on this one.

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

225. By kinoyasu <kinoyasu@gauntlet4> on 2011-04-25

expand innodb_pass_corrupt_table, 2: readonly for not-corrupted index, 3: readonly whole for salvage like force_recovery=1

224. By Alexey Kopytov on 2011-04-20

Merge from lp:percona-server

223. By Alexey Kopytov on 2011-04-20

LP bug #764395 / MySQL bug #60788: InnoDB crashes with an assertion
                                   failure when receiving a signal on
                                   pwrite()

The problem was that InnoDB I/O code was not fully conforming to the
standard on POSIX systems. fsync(), pread() and pwrite() calls may be
interrupted by a signal. In such a case, InnoDB would just fail with an
assertion failure rather than just restarting the interrupted call.

Fixed InnoDB I/O code so that the interrupted system calls are restarted
if they are interrupted by a signal.

222. By Laurynas Biveinis on 2011-04-14

Merge from lp:~percona-dev/percona-server/bug-759688

221. By Yasufumi Kinoshita <kinoyasu@rynex6> on 2011-04-14

fix bug758891, directly. It was the bug only affects to UNIV_DEBUG path

220. By Alexey Kopytov on 2011-04-12

Bug #757749: main.handler_innodb fails in 5.5.11

Using ALTER TABLE to convert an InnoDB table to a MEMORY table could
fail due to a bug in innodb_expand_fast_index_creation.patch.

The problem in innodb_expand_fast_index_creation.patch was that for
ALTER TABLE ENGINE=... the code mistakenly made sure the original
table's engine is InnoDB, rather than the target's one. This resulted in
a failure if the target engine was MEMORY because it does not support
certain handler calls.

Fixed by making sure the target engine is InnoDB, not the original ones.

219. By Alexey Kopytov on 2011-04-03

Merge from trunk

218. By Alexey Kopytov on 2011-03-31

Bug #744103: Make use of InnoDB fast index creation in mysqldump, ALTER
TABLE and OPTIMIZE TABLE

Initial implementation of innodb_expand_fast_index_creation.patch.

This patch expands the applicability of InnoDB fast index creation to
mysqldump, ALTER TABLE and OPTIMIZE TABLE as follows:

1. mysqldump has now a new option, --innodb-optimize-keys, which changes
the way InnoDB tables are dumped so that secondary and foreign keys are
created after loading the data thus taking advantage of fast index
creation.

This part of the patch is an implementation of the feature request
reported as MySQL bug #49120.

More specifically:

- KEY, UNIQUE KEY and CONSTRAINT specifications are omitted from CREATE
TABLE corresponding to InnoDB tables.

- an additional ALTER TABLE is issued after dumping the data to create
the previously omitted keys.

Delaying foreign key creation does not introduce any additional risks as
mysqldump always prepends its output with SET FOREIGN_KEY_CHECKS=0 anyway.

2. When ALTER TABLE requires a table copy, secondary keys are now dropped
and recreated later after copying the data. The following restrictions
apply:

- only non-unique keys can be involved in this optimization

- if the table contains foreign keys, or a foreign key is being added as
a part of the current ALTER TABLE statement, the optimization is
disabled for all keys.

This part of the patch is an implementation of the feature request
reported as MySQL bug #57583.

3. As OPTIMIZE TABLE is mapped to ALTER TABLE ... ENGINE=InnoDB for
InnoDB tables, it now also benefits from fast index creation with the
same restrictions as for ALTER TABLE.

217. By Alexey Kopytov on 2011-03-31

Fixed a recently introduced compiler warning in innodb_expand_import.patch

216. By Alexey Kopytov on 2011-03-31

Fixed broken percona-support.patch.