lp://qastaging/~percona-dev/percona-server/release-5.1.57-12-rnt-backup

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

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

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.

165. By Alexey Kopytov on 2011-05-15

The percona_timestamp_no_default test failed due to a bug in the test file.

164. By Oleg Tsarev on 2011-05-07

rpl_utility.cc => create_conversion_table function used column count from event (doesnt' check column count on slave table)
If you drop some columns on slave, input RBR-event from master crash the server
I added additional check, and now slave just exit with slave error.

163. By Alexey Kopytov on 2011-04-29

Initial implementation of timestamp_no_default.patch.

This patch allows creating TIMESTAMP columns with no default values. It
is impossible in MySQL for legacy reasons, so a TIMESTAMP column without
an explicitly specified default will implicitly be defined with one
of CURRENT_TIMESTAMP, NULL, or 0 as the default value.

In order to not break legacy behavior, a special syntax TIMESTAMP NOT
NULL DEFAULT NULL should be used in CREATE TABLE to avoid defining
implicit defaults for a TIMESTAMP column.

SHOW CREATE TABLE was also updated to produce that syntax for no default
TIMESTAMP columns.

This patch also fixes MySQL bug #33887.