lp:~percona-dev/percona-server/5.1.57-partially-ported

Created by Oleg Tsarev and last modified
Get this branch:
bzr branch lp:~percona-dev/percona-server/5.1.57-partially-ported
Members of Percona developers can upload to this branch. Log in for directions.

Branch merges

Related bugs

Related blueprints

Branch information

Recent revisions

225. By Oleg Tsarev

Patches ported to 5.1.57
ATTENTION, ATTENTION, ATTENTION
!!!
Some parts of innodb_split_buf_pool_mutex.patch was removed (for apply another patches)
You should revert changes in this commit from patch and do their right

!!!
innodb_lru_dump_restore.patch has some changes, what should be reviewed

!!!
mysql-test.diff - I removed part for "mysql-test/include/mtr_warnings.sql", should be restored and fixed

All other looks fine.

UNFORTUNATELY, MYSQL DOESN'T BUILD (Compilation error in InnoDB).

ATTENTION, ATTENTION, ATTENTION

224. By Alexey Kopytov

Merge from lp:percona-server

223. By Alexey Kopytov

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.

221. By Yasufumi Kinoshita <kinoyasu@rynex6>

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

220. By Alexey Kopytov

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

Merge from trunk

218. By Alexey Kopytov

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

Fixed a recently introduced compiler warning in innodb_expand_import.patch

216. By Alexey Kopytov

Fixed broken percona-support.patch.

Branch metadata

Branch format:
Branch format 6
Repository format:
Bazaar pack repository format 1 (needs bzr 0.92)
This branch contains Public information 
Everyone can see this information.