lp:~akopytov/percona-server/bug797944

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

175. By Alexey Kopytov on 2011-06-16

Attempt to fix bug #797944 (since the test failure is sporadic and I
can't reproduce it locally).

Use replication "macros" from include/ rather than custom error
checking code.

174. By Oleg Tsarev on 2011-06-15

merge replication_slave_skip_columns.patch

173. By Oleg Tsarev on 2011-06-15

port to 5.1.57 (merge with lp:percona-server/5.1)

172. By Oleg Tsarev on 2011-06-15

move tests from patches to mysql-test-rnt.diff. I check what this commit correct in following way:
bzr update -r 171
PERCONA_SERVER=a make main
bzr update -r 172
PERCONA_SERVER=b make main
diff -ruN a b # should be empty if transformation is correct

171. By Oleg Tsarev on 2011-06-15

Reorder patch applying (series). Need for port to 5.1.57

170. By Oleg Tsarev on 2011-06-13

fix count of tests in install_tests.sh

169. By Oleg Tsarev on 2011-06-13

fix Makefile and install_tests.sh (update from lp:percona-server/5.1)

168. By Alexey Kopytov on 2011-06-03

Support for fast growing VARCHAR fields in InnoDB.

When ALTER TABLE modifies a VARCHAR column so that its length is
increased in a compatible way (i.e. the old length and the new one are
either both <= 255 or both <= 65535), it is possible to avoid table copy
and only update metadata.

This revision updates rename_field.patch so that in addition to fast
field renaming for InnoDB tables, growing VARCHAR columns can also be
performed without data copying by updating the appropriate fields in
InnoDB data dictionary.

To keep the patch name consistent with the updated functionality, the
patch has been renamed to innodb_fast_alter_column.patch, and the server
variable that controls the functionality has been renamed from
innodb_internal_rename_field to innodb_fast_alter_column.

This revision also adds test cases for both fast renames and fast
VARCHAR growing.

167. By Oleg Tsarev on 2011-05-31

fix tests: funcs_1.is_engines_innodb funcs_1.is_columns_is funcs_1.storedproc funcs_1.is_tables_is percona_server_variables

166. By Alexey Kopytov on 2011-05-15

Fix for MySQL bug #54127: mysqld segfaults when built using
--with-max-indexes=128

When using a non-default MAX_KEY value, a different code path is used
when processing index bitmaps. With the default value of 64, the
optimized "template <> class Bitmap<64>" is used which represents and
processes bitmaps as 64-bit integeres. Otherwise, "template <uint
default_width> class Bitmap" is used in which case bitmaps are
represented as arrays.

Multiple problems with the "non-optimized" Bitmap class were discovered
when testing a server binary built with --with-max-indexes=128:

1. bitmap_set_prefix() could overrun the internal buffer when resetting
the remainder of the buffer after setting the prefix due to an
incorrectly calculated remainder's length. This was the reason for the
crash on startup in MySQL bug #54127.

2. Bitmap::intersect() did not take into account that bitmap_init()
resets the supplied buffer, so an intersection with a zero bitmap was
always calculated (reported as MySQL #61178). This led to numerous test
failures due to different execution plans produced by the optimizer.

3. Bitmap::to_ulonglong() incorrectly calculated the result value due to
serious bugs in [u]int*korr/[u]int*store set of macros in
my_global.h (reported as MySQL bugs #61179 and #61180). This led to test
failures in distinct.test and group_min_max.test.

There are still a number of failing tests when running the test suite
with --with-max-indexes=128:

- create.test contains a test case explicitly testing the 64-bit index
limit;

- the ps_N* series of tests verifies the metadata sent by EXPLAIN, where
the field length of "possible_keys" and "key_len" columns depends on
the MAX_KEY value and hence, is different for a binary built with a
non-default value of --with-max-indexes.