Commit graph

180832 commits

Author SHA1 Message Date
Marko Mäkelä
a7f84f09bf MDEV-16865 InnoDB fts_query() ignores KILL
The functions fts_ast_visit() and fts_query() inside
InnoDB FULLTEXT INDEX query processing are not checking
for THD::killed (trx_is_interrupted()), like anything
that potentially takes a long time should do.

This is a port of the following change from MySQL 5.7.23,
with a completely rewritten test case.

commit c58c6f8f66ddd0357ecd0c99646aa6bf1dae49c8
Author: Aakanksha Verma <aakanksha.verma@oracle.com>
Date:   Fri May 4 15:53:13 2018 +0530

Bug #27155294 MAX_EXECUTION_TIME NOT INTERUPTED WITH FULLTEXT SEARCH USING MECAB
2018-08-01 08:43:12 +03:00
Marko Mäkelä
b3e95086e1 Fix function pointer type mismatch 2018-08-01 08:43:12 +03:00
Daniel Bartholomew
33110db055 bump the VERSION 2018-07-31 10:46:16 -04:00
Alexey Botchkov
f4eac2deeb MDEV-16054 simple json functions flatline cpu on garbage input.
Incorrect char sentence should be handled properly.
2018-07-31 16:33:05 +04:00
Marko Mäkelä
87ec6a0448 Merge 10.0 into 10.1 2018-07-31 15:19:56 +03:00
Elena Stepanova
e023f9a4d5 Unstable tests for 10.0.36 release, latest additions 2018-07-31 15:19:01 +03:00
Oleksandr Byelkin
865e807125 Merge branch '10.0' into 10.1 2018-07-31 11:58:29 +02:00
Marko Mäkelä
e52315a4a2 MDEV-16855 Fix fts_sync_synchronization in InnoDB
This is a backport of the following fix from MySQL 5.7.23.
Some code refactoring has been omitted, and the test case has
been adapted to MariaDB.

commit 7a689acaa65e9d602575f7aa53fe36a64a07460f
Author: Krzysztof Kapuścik <krzysztof.kapuscik@oracle.com>
Date:   Tue Mar 13 12:34:03 2018 +0100

Bug#27082268 Invalid FTS sync synchronization

The fix closes two issues:
Bug #27082268 - INNODB: FAILING ASSERTION: SYM_NODE->TABLE != NULL DURING FTS SYNC
Bug #27095935 - DEADLOCK BETWEEN FTS_DROP_INDEX AND FTS_OPTIMIZE_SYNC_TABLE

Both issues were related to a FTS cache sync being done during
operations that perfomed DDL actions on internal FTS tables
(ALTER TABLE, TRUNCATE). In some cases the FTS tables and/or
internal cache structures could get removed while still being
used to perform FTS synchronization leading to crashes. In other
the sync operations could not get finishes as it was waiting for
dict lock which was taken by thread waiting for the background
sync to be finished.

The changes done includes:
- Stopping background operations during ALTER TABLE and TRUNCATE.
- Removal of unused code in FTS.
- Cleanup of FTS sync related code to make it more readable and
easier to maintain.

RB#18262
2018-07-30 18:06:30 +03:00
Marko Mäkelä
5ed2da9587 Apply the 5.6.40 security fixes to XtraDB
We did not merge Percona XtraDB 5.6.40-84.0 yet.
The changes in it are mostly cosmetic, except for
2 bug fixes from Oracle MySQL 5.6.40, which could
be security bugs.

This was achieved by taking the applicable parts
of an earlier InnoDB commit to XtraDB:

git diff 15ec8c2f28f08517ecbffb959d756b4bdd53ab45{~,} storage/innobase|
sed -e s+/innobase/+/xtradb/+|patch -p1
2018-07-30 16:28:20 +03:00
Marko Mäkelä
7c773abdf7 Merge 5.5 into 10.0 2018-07-30 15:44:31 +03:00
Karthik Kamath
a49ec98042 2018-07-30 15:32:22 +03:00
Marko Mäkelä
4c21c367b3 Merge InnoDB MySQL 5.6.41 to 10.0 2018-07-30 15:21:11 +03:00
Sachin Agarwal
29ddc6e9e3 Bug #27326796 - MYSQL CRASH WITH INNODB ASSERTION FAILURE IN FILE PARS0PARS.CC
Problem:
As part of bug #24938374 fix, dict_operation_lock was not taken by
fts_optimize_thread while syncing fts cache.
Due to this change, alter query is able to update SYS_TABLE rows
simultaneously. Now when fts_optimizer_thread goes open index table,
It doesn't open index table if the record corresponding to that table is
set to REC_INFO_DELETED_FLAG in SYS_TABLES and hits an assert.

Fix:
If fts sync is already in progress, Alter query would wait for sync to
complete before renaming table.

RB: #19604
Reviewed by : Jimmy.Yang@oracle.com
2018-07-30 15:18:51 +03:00
Marko Mäkelä
91181b225c Merge 5.5 into 10.0 2018-07-30 15:09:25 +03:00
mleich1
fd378fc613 MDEV-16809 Allow full redo logging for ALTER TABLE
Add the usual basic test for the variable innodb_log_optimize_ddl.

Signed-off-by: mleich1 <Matthias.Leich@mariadb.com>
2018-07-30 13:55:24 +02:00
Marko Mäkelä
d17e9a02c4 Fix InnoDB/XtraDB warnings by GCC 8.2.0 2018-07-30 14:05:24 +03:00
Marko Mäkelä
8bdd125067 MDEV-16851 On schema mismatch in IMPORT TABLESPACE, display ROW_FORMAT in clear text
This is motivated by Oracle MySQL Bug #27542720 SCHEMA MISMATCH
- TABLE FLAGS DON'T MATCH, BUT FLAGS ARE NUMBERS
but using a different approach.

row_import::match_schema(): In case of a mismatch, display the
ROW_FORMAT and optionally KEY_BLOCK_SIZE of the .cfg file.
2018-07-30 13:13:43 +03:00
Marko Mäkelä
340963351c Use a more precise argument for memset() 2018-07-30 10:39:42 +03:00
Oleksandr Byelkin
fceda2dab6 Merge remote-tracking branch 'mysql/5.5' into 5.5
We do not accept:
1. We did not have this problem (fixed earlier and better)
 d982e717ab Bug#27510150: MYSQLDUMP FAILS FOR SPECIFIC --WHERE CLAUSES
2. We do not have such options (an DBUG_ASSERT put just in case)
 bbc2e37fe4 Bug#27759871: BACKRONYM ISSUE IS STILL IN MYSQL 5.7
3. Serg fixed it in other way in this release:
 e48d775c6f Bug#27980823: HEAP OVERFLOW VULNERABILITIES IN MYSQL CLIENT LIBRARY
2018-07-29 13:10:29 +02:00
Jan Lindström
14306bcbec MDEV-16831: Galera test failure on galera_sst_mysqldump_with_key
Test case was not written correctly.
2018-07-27 10:05:26 +03:00
Varun Gupta
bd0b368119 Fix added along with a test for a case missed in the patch for MDEV-16751 2018-07-27 11:34:34 +05:30
Julius Goryavsky
46d5e1f2fd MDEV-10754 wsrep_sst_rsync does not support innodb_data_home_dir
If innodb_data_home_dir path specified in the configuration file
then rsync IST/SST will fail because the wsrep_sst_rsync.sh script
does not read this parameter from the configuration file and then
tries to find the data files in the default directory.

To fix this error, we need to add reading of the innodb_data_home_dir
configuration parameter to the rsync-related SST script.
2018-07-26 15:44:28 +02:00
Alexander Barkov
5c5a116b47 MDEV-16614 signal 7 after calling stored procedure, that uses regexp
The problem happened in the derived condition pushdown code:
- When Item_func_regex::build_clone() was called, it created a copy of
  the original Item_func_regex, and this copy got registered in free_list.
  Class specific additional dynamic members (such as "re") made
  a shallow copy, rather than a deep copy, in the cloned Item_func_regex.
  As a result, the Regexp_processor_pcre::m_pcre of the cloned Item_func_regex
  and of the original Item_func_regex pointed to the same compiled regular
  expression.
- On cleanup_items(), both original and cloned copies of Item_func_regex
  called re.cleanup(), which called pcre_free(m_pcre). So the same compiled
  regular expression was freed two times, which was noticed by ASAN.

The same problem was repeatable for Item_func_regexp_instr.

A similar problem happened for Item_func_sp, for the sp_result_field member.
Both original and cloned copies of Item_func_sp pointed the same Field instance
and both deleted it on cleanup().

A possible solution would be to fix build_clone() to create deep
(instead of shallow) copies for the dynamic members of the affected classes
(Item_func_regex, Item_func_regexp_instr, Item_func sp).
However, this would be too complex.

As agreed with Galina and Igor, this patch disallows using using these
affected classes in derived condition pushdown by overriding get_clone()
to return NULL.
2018-07-26 13:05:22 +04:00
Igor Babaev
3c141e319a MDEV-15087 Item_func::fix_fields:
Assertion `used_tables_cache == 0' failed

This bug manifested itself when executing queries
over materialized derived tables /vies and with
conjunctive always true predicates containing
inexpensive single-row subqueries.
This bug disappeared after the patch mdev-15035
had been applied.
2018-07-25 23:29:48 -07:00
Marko Mäkelä
0f90728bc0 MDEV-16809 Allow full redo logging for ALTER TABLE
Introduce the configuration option innodb_log_optimize_ddl
for controlling whether native index creation or table-rebuild
in InnoDB should keep optimizing the redo log
(and writing MLOG_INDEX_LOAD records to ensure that
concurrent backup would fail).

By default, we have innodb_log_optimize_ddl=ON, that is,
the default behaviour that was introduced in MariaDB 10.2.2
(with the merge of InnoDB from MySQL 5.7) will be unchanged.

BtrBulk::m_trx: Replaces m_trx_id. We must be able to check for
KILL QUERY even if !m_flush_observer (innodb_log_optimize_ddl=OFF).

page_cur_insert_rec_write_log(): Declare globally, so that this
can be called from PageBulk::insert().

row_merge_insert_index_tuples(): Remove the unused parameter trx_id.

row_merge_build_indexes(): Enable or disable redo logging based on
the innodb_log_optimize_ddl parameter.

PageBulk::init(), PageBulk::insert(), PageBulk::finish(): Write
redo log records if needed. For ROW_FORMAT=COMPRESSED, redo log
will be written in PageBulk::compress() unless we called
m_mtr.set_log_mode(MTR_LOG_NO_REDO).
2018-07-26 08:44:42 +03:00
Marko Mäkelä
32eb5823e4 Remove pointer indirection for BtrBulk::m_page_bulks 2018-07-26 08:44:41 +03:00
Marko Mäkelä
4a456eac2a Remove unused BtrBulk::m_heap 2018-07-26 08:44:41 +03:00
Marko Mäkelä
a3b22147ca Remove pointer indirection for PageBulk::m_mtr 2018-07-26 08:44:41 +03:00
Marko Mäkelä
172199b88c PageBulk: Remove dead code
Native ALTER TABLE is never invoked on temporary tables.
2018-07-26 08:44:41 +03:00
Marko Mäkelä
7f54894329 Remove mtr_set_flush_observer() 2018-07-26 08:44:41 +03:00
Oleksandr Byelkin
189157d052 Merge branch '10.1' into bb-10.1-merge-sanja 2018-07-26 06:34:33 +02:00
Oleksandr Byelkin
cb5952b506 Merge branch '10.0' into bb-10.1-merge-sanja 2018-07-25 22:24:40 +02:00
Igor Babaev
aad70e9b4c MDEV-16820 Lost 'Impossible where' from query with inexpensive subquery
This patch fixes another problem introduced by the patch for mdev-4817.
The latter changed Item_cond::fix_fields() in such a way that it could
call the virtual method is_expensive(). With the first its call
the method saves the result in Item::is_expensive_cache. For all next
calls the method returns the result from this cache. So if the item
once was determined as expensive the method always returns true.
For subqueries it's not good, because non-optimized subqueries always
is considered as expensive.
It means that the cache should be invalidated after the call of
optimize_constant_subqueries().
2018-07-25 11:58:19 -07:00
Varun Gupta
37dee22d27 MDEV-15454: Nested SELECT IN returns wrong results
In this case we are setting the field Item_func_eq::in_eqaulity_no for the semi-join equalities.
This helps us to remove these equalites as the inner tables are not available during parent select execution
while the outer tables are not available during materialization phase.
We only have it set for the equalites for the fields involved with the IN subquery
and reset it for the equalities which do not belong to the IN subquery.

For example in case of nested IN subqueries:

    SELECT t1.a FROM t1 WHERE t1.a IN
      (SELECT t2.a FROM t2 where t2.b IN
          (select t3.b from t3 where t3.c=27 ))

there are two equalites involving the fields of the IN subquery

1) t2.b = t3.b :  the field Item_func_eq::in_eqaulity_no is set when we merge the grandchild select into the child select
2) t1.a = t2.a :  the field Item_func_eq::in_eqaulity_no is set when we merge the child select into the parent select

But when we perform case 2) we should ensure that we reset the equalities in the child's WHERE clause.
2018-07-25 21:21:27 +05:30
Varun Gupta
f9b43c2565 MDEV-16751: Server crashes in st_join_table::cleanup or TABLE_LIST::is_with_table_recursive_reference
with join_cache_level>2

During muliple equality propagation for a query in which we have an IN subquery, the items in the select list of the
subquery may not be part of the multiple equality because there might be another occurence of the same field in the
where clause of the subquery.
So we keyuse_is_valid_for_access_in_chosen_plan function which expects the items in the select list of the subquery to
be same to the ones in the multiple equality (through these multiple equalities we create keyuse array).
The solution would be that we expect the same field not the same Item because when we have SEMI JOIN MATERIALIZATION SCAN,
we use copy back technique to copies back the materialised table fields to the original fields of the base tables.
2018-07-25 14:20:16 +05:30
Thirunarayanan Balathandayuthapani
de85355436 MDEV-16713 Hangs server with repeating log entry
At most one transaction can be active at a time for temporary
tables. There is no need to check previous version of record for the
temporary tables.
2018-07-25 13:56:39 +05:30
Sachin
969939e89c MDEV-16821 Set password for user makes rpl test to fail
Actually if we use "set password for " command this changes the checksum
of mysql.user table
-localhost      root            Y       Y       Y       Y       Y       Y       Y       Y     YY       Y       Y       Y       Y       Y       Y       Y       Y       Y       Y       Y     $
Y       Y       Y       Y       Y       Y       Y                                       0     00       0                       N       N               0.000000
+localhost      root            Y       Y       Y       Y       Y       Y       Y       Y     YY       Y       Y       Y       Y       Y       Y       Y       Y       Y       Y       Y     Y
Y       Y       Y       Y       Y       Y       Y                                       0     00       0       mysql_native_password           N       N               0.000000
In short we replace '' with mysql_native_password
which make checksum to be different, and hence check test case fails.

So we use UPDATE mysql.user command.
2018-07-25 12:54:37 +05:30
Igor Babaev
1fde449f1d MDEV-16820 Lost 'Impossible where' from query with inexpensive subquery
This patch fixes another problem introduced by the patch for mdev-4817.
The latter changed Item_cond::fix_fields() in such a way that it could
call the virtual method is_expensive(). With the first its call
the method saves the result in Item::is_expensive_cache. For all next
calls the method returns the result from this cache. So if the item
once was determined as expensive the method always returns true.
For subqueries it's not good, because non-optimized subqueries always
is considered as expensive.
It means that the cache should be invalidated after the call of
optimize_constant_subqueries().
2018-07-24 23:53:12 -07:00
Igor Babaev
c631060713 MDEV-16820 Lost 'Impossible where' from query with inexpensive subquery
This patch fixes another problem introduced by the patch for mdev-4817.
The latter changed Item_cond::fix_fields() in such a way that it could
call the virtual method is_expensive(). With the first its call
the method saves the result in Item::is_expensive_cache. For all next
calls the method returns the result from this cache. So if the item
once was determined as expensive the method always returns true.
For subqueries it's not good, because non-optimized subqueries always
is considered as expensive.
It means that the cache should be invalidated after the call of
optimize_constant_subqueries().
2018-07-24 23:45:55 -07:00
Jan Lindström
57cde8ccd1 MDEV-15822: WSREP: BF lock wait long for trx
In Galera BF (brute force) transactions may not wait for lock requests
and normally BF-transaction would select transaction holding conflicting
locks as a victim for rollback. However, background statistic calculation
transaction is InnoDB internal transaction and it has no thd i.e. it can't be
selected as a victim. If background statistics calculation transaction holds
conflicting locks to statistics tables it will cause BF lock wait long
error message. Correct way to handle background statistics calculation is to
acquire thd for transaction but that change is too big for GA-releases and
there are other reported problems on background statistics calculation.

This fix avoids adding a table to background statistics calculation if
2018-07-25 08:24:09 +03:00
Igor Babaev
d567f1611e MDEV-16820 Lost 'Impossible where' from query with inexpensive subquery
This patch fixes another problem introduced by the patch for mdev-4817.
The latter changed Item_cond::fix_fields() in such a way that it could
call the virtual method is_expensive(). With the first its call
the method saves the result in Item::is_expensive_cache. For all next
calls the method returns the result from this cache. So if the item
once was determined as expensive the method always returns true.
For subqueries it's not good, because non-optimized subqueries always
is considered as expensive.
It means that the cache should be invalidated after the call of
optimize_constant_subqueries().
2018-07-24 20:00:28 -07:00
Elena Stepanova
1bda5e3a8f List of unstable tests for 10.0.36 release 2018-07-24 20:09:42 +03:00
Oleksandr Byelkin
9fbe360e9f make plugins.processlist more robust 2018-07-24 18:29:17 +02:00
Oleksandr Byelkin
e0139c2b92 fix plugins.processlist
make it not to fail when `show engine innodb status` output
contains a double quote
2018-07-24 18:16:41 +02:00
Alexander Barkov
a8227a1543 MDEV-16814 CREATE TABLE SELECT JSON_QUOTE(multibyte_charset_expr) makes a field of a wrong length 2018-07-24 18:15:15 +04:00
Jan Lindström
c863159c32 MDEV-16799: Test wsrep.variables crash at sql_class.cc:639 thd_get_ha_data
Problem was that binlog_hton was not initialized fully when needed
i.e. when wsrep_on = true.
2018-07-24 14:54:50 +03:00
Oleksandr "Sanja" Byelkin
5e67567b15
Merge pull request #726 from fauust/10.0-MDEV-14672
MDEV-14672 Minor upgrade fails on xenial due to missing unixODBC (case-sensitive)
2018-07-24 10:42:35 +02:00
Jacob Mathew
45ab00f097 MDEV-15786: ERROR 1062 (23000) at line 365: Duplicate entry 'spider' for key 'PRIMARY'
The problem occurs on Ubuntu where a Spider package is installed on the system
separately from the MariaDB package.  MariaDB and Spider upgrades leave the
Spider plugin improperly installed.  Spider is present in the mysql.plugin
table but is not present in information_schema.

The problem has been corrected in Spider's installation script.  Logic has
been added to check for Spider entries in both information_schema and
mysql.plugin.  If Spider is present in mysql.plugin but is not present in
information_schema, then Spider is first removed from mysql.plugin.  The
subsequent plugin install of Spider will insert entries in both mysql.plugin
and information_schema.

Author:
  Jacob Mathew.

Reviewer:
  Kentoku Shiba.

Cherry-Picked:
  Commit 0897d81 on branch bb-10.3-MDEV-15786
2018-07-23 14:14:23 -07:00
Marko Mäkelä
9d1f3bf2e9 row_purge_poss_sec(): Add debug instrumentation
This helped fix MDEV-16779.
2018-07-23 18:34:06 +03:00
Marko Mäkelä
c5ba13dda0 MDEV-15855 cleanup: Privatize purge_vcol_info_t
Declare all fields of purge_vcol_info_t private, and add
accessor functions.
2018-07-23 18:31:42 +03:00