lp:~sergei.glushchenko/percona-server/ps51-128-max-index-gca

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

3660. By Sergei Glushchenko on 2012-09-17

This is a merge of fix for --with-max-indexes=128 by Alexey Kopytov.
This fix originally was committed to lp:percona-server/rnt-5.1.
Original commit message is:
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.

The workaround was implemented for failing tests.
include/have_64_keys.inc verify MAX_INDEXES by requesting EXPLAIN
metadata and if MAX_INDEXES is different from default value the
test is skipped.

3659. By Georgi Kodinov on 2012-04-10

merge mysql-5.1->mysql-5.1-security

3658. By Georgi Kodinov on 2012-04-06

Bug #13934049: 64884: LOGINS WITH INCORRECT PASSWORD ARE ALLOWED

Fixed an improper type conversion on return that can make the server accept
logins with a wrong password.

3657. By Sergey Glukhov on 2012-04-04

Bug#11766300 59387: FAILING ASSERTION: CURSOR->POS_STATE == 1997660512 (BTR_PCUR_IS_POSITIONE
Bug#13639204 64111: CRASH ON SELECT SUBQUERY WITH NON UNIQUE INDEX
The crash happened due to wrong calculation
of key length during creation of reference for
sort order index. The problem is that
keyuse->used_tables can have OUTER_REF_TABLE_BIT enabled
but used_tables parameter(create_ref_for_key() func) does
not have it. So key parts which have OUTER_REF_TABLE_BIT
are ommited and it could lead to incorrect key length
calculation(zero key length).

3656. By Georgi Kodinov on 2012-03-21

empty weave merge mysql-5.0-security->mysql-5.1-security

3655. By Georgi Kodinov on 2012-03-21

merge mysql-5.1->mysql-5.1-security

3654. By Norvald H. Ryeng on 2012-03-12

Bug#13031606 VALUES() IN A SELECT STATEMENT CRASHES SERVER

Problem: Grouping results by VALUES(alias for string literal) causes
the server to crash.

Item_insert_values is not constructed to handle other types of
arguments than field and reference to field. In this case, the
argument is an Item_string, and this causes
Item_insert_values::fix_fields() to crash.

Fix: Issue an error message when the argument to Item_insert_values is
not a field or a reference to a field.

This is slightly in breach with documentation, which states that
VALUES should return NULL, but the error message is only issued in
cases where the server otherwise would crash, so there is no change in
behavior for queries that already work. Future versions will restrict
syntax so that using VALUES in this way is illegal.

3653. By Dmitry Lenev <email address hidden> on 2012-03-11

Fixed test case for bug #13105873 "valgrind warning:possible
crash in foreign key handling on subsequent create table if
not exists".

Do not leave current database unassigned after the end of
the test case.

3652. By Georgi Kodinov on 2012-03-08

empty weave merge mysql-5.0-security->mysql-5.1-security

3651. By Georgi Kodinov on 2012-03-08

merge mysql-5.1->mysql-5.1-security