diff options
| author | Vladislav Vaintroub <wlad@mariadb.com> | 2019-05-09 17:38:22 +0200 |
|---|---|---|
| committer | Vladislav Vaintroub <wlad@mariadb.com> | 2019-05-09 18:58:16 +0200 |
| commit | ad36d38024cf82724f5e9589fc9fe4ad57fcf390 (patch) | |
| tree | c4921ca39005b5709ff1287f086de708ddd8f5ad /mysql-test/main/mysql_client_test.test | |
| parent | 44b8b002f56d5d0c5da3d600276965c41d9ab7bf (diff) | |
| download | mariadb-git-ad36d38024cf82724f5e9589fc9fe4ad57fcf390.tar.gz | |
MDEV-19235 MariaDB Server compiled for 128 Indexes crashes at startupbb-10.4-wlad-MDEV-19235
With MAX_INDEXIES=64(default), key_map=Bitmap<64> is just a wrapper around
ulonglong and thus "trivial" (can be bzero-ed, or memcpy-ed, and stays
valid still)
With MAX_INDEXES=128, key_map = Bitmap<128> is not a "trivial" type
anymore. The implementation uses MY_BITMAP, and MY_BITMAP contains pointers
which make Bitmap invalid, when it is memcpy-ed/bzero-ed.
The problem in 10.4 is that there are many new key_map members, inside TABLE
or KEY, and those are often memcopied and bzeroed
The fix makes Bitmap "trivial", by inlining most of MY_BITMAP functionality.
pointers/heap allocations are not used anymore.
Diffstat (limited to 'mysql-test/main/mysql_client_test.test')
| -rw-r--r-- | mysql-test/main/mysql_client_test.test | 4 |
1 files changed, 4 insertions, 0 deletions
diff --git a/mysql-test/main/mysql_client_test.test b/mysql-test/main/mysql_client_test.test index 2c6febd8ffa..a4da24c448f 100644 --- a/mysql-test/main/mysql_client_test.test +++ b/mysql-test/main/mysql_client_test.test @@ -32,6 +32,10 @@ echo ok; --echo --echo # cat MYSQL_TMP_DIR/test_explain_meta.out.log --echo # ------------------------------------ + +# For MAX_INDEXES=128, max_len for possible_keys column is twice as large vs MAX_INDEXES=64 +--replace_result 24576 12288 + --cat_file $MYSQL_TMP_DIR/test_explain_meta.out.log --echo # ------------------------------------ --echo |