1
0
mirror of https://github.com/MariaDB/server.git synced 2025-07-18 23:03:28 +03:00
Commit Graph

4614 Commits

Author SHA1 Message Date
65d48b4a7b Merge 10.2 to 10.3 2019-08-13 19:28:51 +03:00
f25e9aa4ba MDEV-20310: Make InnoDB crash tests Valgrind-friendly
Use DEBUG_SYNC to hang the execution at the interesting point,
and then kill and restart the server externally. This will work
also with Valgrind. DBUG_SUICIDE() causes Valgrind to hang,
and it could also cause uninteresting reports about memory leaks.

While we are at it, let us clean up innodb.innodb_bulk_create_index_debug
so that it will actually test the desired functionality also in future
versions (with instant ADD COLUMN and DROP COLUMN) and avoid
some unnecessary restarts.

We are adding two DEBUG_SYNC points for ALTER TABLE, because there were
none that would be executed right before ha_commit_trans().
2019-08-13 13:32:27 +03:00
95cdc1ca5f Merge commit '43882e764d6867c6855b1ff057758a3f08b25c55' into 10.4 2019-08-13 11:42:31 +04:00
be33124c9d Merge 10.1 into 10.2 2019-08-12 18:25:35 +03:00
22914ec793 MDEV-18154 Deadlock and assertion upon no-op ALTER under LOCK TABLES
1. Fix DBUG_ASSERT(!table->pos_in_locked_tables) in tc_release_table();
2. Fix access of prematurely freed MDL_ticket: don't close ticket if table was not closed;
3. Fix deadlock after erroneous ALTER.

mysql_alter_table() leaves dirty table->m_needs_reopen in case of
error exit which then incorrectly treated by mysql_lock_tables().
2019-08-11 12:32:08 +03:00
638e78853f MDEV-18862 Unfortunate error message upon attempt to drop system versioning
Special case for DROP PERIOD when system fields are implicit.
2019-08-11 12:32:08 +03:00
eef7540405 MDEV-18930: Failed CREATE OR REPLACE TEMPORARY not written into binary log makes data on master and slave diverge
Problem:
=======
Failed CREATE OR REPLACE TEMPORARY TABLE statement which dropped the table but
failed at a later stage of creation of temporary table is not written to
binarylog in row based replication. This causes the slave to diverge.

Analysis:
========
CREATE OR REPLACE statements work as shown below.

CREATE OR REPLACE TABLE table_name (a int);
is basically the same as:

DROP TABLE IF EXISTS table_name;
CREATE TABLE table_name (a int);

Hence every CREATE OR REPLACE TABLE command which dropped the table should be
written to binary log, even when following CREATE TABLE part fails. In order
to achieve this, during the execution of CREATE OR REPLACE command, when a
table is dropped 'thd->log_current_statement' flag is set. When table creation
results in an error within 'mysql_create_table' code, the error handling part
looks for this flag. If it is set the failed CREATE OR REPLACE statement is
written into the binary log inspite of error. This ensure that slave doesn't
diverge from the master. In case of row based replication the error handling
code returns very early, if the table is of type temporary. This is done based
on the assumption that temporary tables are not replicated in row based
replication.

It fails to handle the cases where a temporary table was created as part of
statement based replication at an earlier stage and the binary log format was
changed to row because of an unsafe statement. In this case when a CREATE OR
REPLACE statement is executed on this temporary table it will dropped but the
query will not be written to binary log. Hence slave diverges.

Fix:
===
In error handling code check the return status of create table operation. If
it is successful and replication mode is row based and table is of type
temporary then return. Other wise proceed further to the code which checks for
thd->log_current_statement flag and does appropriate logging.
2019-08-05 14:34:31 +05:30
c6efbc543d MDEV-17544 No warning when trying to name a primary key constraint.
Warning added.
2019-07-30 21:57:48 +04:00
2792c6e7b0 Merge branch '10.3' into 10.4 2019-07-28 13:43:26 +02:00
d97342b6f2 Merge branch '10.2' into 10.3 2019-07-26 22:42:35 +02:00
cf8c2a3c3b Merge branch '10.1' into 10.2 2019-07-26 07:03:39 +02:00
e9c1701e11 Merge 10.3 into 10.4 2019-07-25 18:42:06 +03:00
fdef9f9b89 Merge 10.2 into 10.3 2019-07-25 15:31:11 +03:00
ae476868a5 Merge branch '5.5' into 10.1 2019-07-25 13:27:11 +02:00
b6ac67389d Merge 10.1 into 10.2 2019-07-25 12:14:27 +03:00
e32f29b7f3 MDEV-20091 DROP TEMPORARY table is logged despite no CREATE was logged
MDEV-5589 commit set up a policy to skip DROP TEMPORARY TABLE binary logging
in case the target table has not been "CREATEed" in binlog (no CREATE
Query-log-event was logged into the binary log).

It turns out that

1. the rule did not cover non-existing table DROPped with IF-EXISTS clause.
   The logged-create knowledge for the non-existing one does not even need
   MDEV-5589 patch, and

2. connection close disobeys it to trigger automatic DROP-IF-EXISTS
   binlogging.

Either 1 or 2 or even both is/are also responsible for unexpected binlog
records observed in MDEV-17863, actually rendering a referred
@@global.read_only irrelevant as far as the described stored procedure
definition *and* the ROW binlog-format are concerned.
2019-07-25 11:38:45 +05:30
2536c0b1eb BUG#28642318: POINT IN TIME RECOVERY USING MYSQLBINLOG BROKEN WITH TEMPORARY TABLE -> ERRORS
Analysis
========
Point in time recovery using mysqlbinlog containing queries
operating on temporary tables results in an error.

While writing the query log event in the binary log, the
thread id used for execution of DROP TABLE and DELETE commands
were incorrect. The thread variable 'thread_specific_used'
is used to determine whether a specific thread id is to used
while executing the statements i.e using 'SET
@@session.pseudo_thread_id'. This variable was not set
correctly for DROP TABLE query and was never set for DELETE
query. The thread id is important for temporary tables
since the tables are session specific. DROP TABLE and DELETE
queries executed using a wrong thread id resulted in errors
while applying the queries generated by mysqlbinlog utility.

Fix
===
Set the 'thread_specific_used' THD variable for DROP TABLE and
DELETE queries.

ReviewBoard: 21833
2019-07-24 18:32:24 +02:00
0f83c8878d Merge 10.2 into 10.3 2019-07-16 18:39:21 +03:00
a0230bc76d MDEV-18266 Changing an index comment unnecessarily rebuilds index
ALTER_CHANGE_INDEX_COMMENT: new handler flag added

Compare_keys::EqualButComment: new outcome of compare_keys_but_name()
2019-07-10 21:36:29 +03:00
64900e3d7c MDEV-15641 InnoDB crash while committing table-rebuilding ALTER TABLE
Problem:
========
 There is a possibility that there can be more concurrent DMLs While the
alter table thread is waiting for upgrading to MDL_EXCLUSIVE before commit phase.
In commit phase, InnoDB acquires dict_operation_lock and it already holds MDL_EXCLUSIVE
on the table. After that, InnoDB applies the concurrent DML logs in commit phase.
This could lead to blocking of the following things:

  1) DML on the particular table (due to MDL_EXCLUSIVE on the table)
  2) InnoDB DDLs (due to dict_operation_lock)
  3) Purge thread, stats thread, the master thread (due to dict_operation_lock)

Fix:
====
Apply the concurrent DML logs in commit phase but before acquiring
dict_operation_lock in commit phase. It makes sure that (2), (3) can't be
blocked for longer time.
2019-07-10 12:43:51 +05:30
cf7a8b9eb2 MDEV-16222 Assertion `0' failed in row_purge_remove_sec_if_poss_leaf on table with virtual columns and indexes
Cause
Stale thd->m_stmt_da->m_sql_errno which is from different invocation.

Fix
Reset error state before attempt to open table.
2019-07-09 10:01:54 +03:00
53dd0e4f75 MDEV-16222 Assertion `0' failed in row_purge_remove_sec_if_poss_leaf on table with virtual columns and indexes
Cause
Stale thd->m_stmt_da->m_sql_errno which is from different invocation.

Fix
Reset error state before attempt to open table.
2019-07-08 20:14:51 +03:00
6974962945 MDEV-16222 Assertion `0' failed in row_purge_remove_sec_if_poss_leaf on table with virtual columns and indexes
Cause
Stale thd->m_stmt_da->m_sql_errno which is from different invocation.

Fix
Reset error state before attempt to open table.
2019-07-08 14:55:59 +03:00
04ee96199e MDEV-19049 Server crashes in check_duplicate_long_entry_key, ASAN stack-buffer-overflow in Field_blob::get_key_image
Long Unique keys should always be last unique key.
2019-06-26 11:31:26 +05:30
a82e42fd13 NFC: refactor Field::is_equal() and related stuff
Make Field::is_equal() const and return bool as it's a naturally fitting
type for it. Also it's agrument was narrowed to Column_definition.

InnoDB can change type of some columns by itself. InnoDB-specific code used to
reside in Field_xxx:is_equal() methods. Now engine-specific stuff was
moved to a virtual methods of handler::can_convert{string,varstring,blob,geom}.
These methods are called by Field::can_be_converted_by_engine() which is a
double dispatch pattern.

Some InnoDB-specific code still resides in compare_keys_but_name(). It should
be moved from here someday to handler::compare_key_parts(...) or similar.

IS_EQUAL_WITH_REINTERPRET_COMPATIBLE_CHARSET
IS_EQUAL_WITH_REINTERPRET_COMPATIBLE_CHARSET_BUT_COLLATE: both was removed

IS_EQUAL_NO, IS_EQUAL_YES are not needed now and should be removed
along with deprecated handler::check_if_incompatible_data().

HA_EXTENDED_TYPES_CONVERSION: was removed as such logic is not needed now by
server code.

ALTER_COLUMN_EQUAL_PACK_LENGTH: was renamed to a more generic
ALTER_COLUMN_TYPE_CHANGE_BY_ENGINE
2019-06-22 14:09:12 +03:00
854c219a7f MDEV-17301 Change of COLLATE unnecessarily requires ALGORITHM=COPY
Patch is about two cases:
1) On some collate changes it's possible to rebuild only secondary indexes
2) For non-indexed columns collate can be changed INSTANTly

Implemented mostly in Field_{string,varstring,blob}::is_equal().
Make this method return how exactly collationa differs.
This information is later used by fill_alter_inplace_info() to pass
correct info to engine.
2019-06-22 14:09:12 +03:00
02979daab4 Merge 10.3 into 10.4 2019-06-19 10:49:00 +03:00
192aa295b4 Merge 10.2 into 10.3 2019-06-19 08:56:10 +03:00
c8b5fa4afc MDEV-19055 Failures with temporary tables and Aria
There was two separate problems:
- Aria pagecache didn't properly handle re-reading of blocks
  that have given errors before (this triggered an assert)
- temporary tables that where opened several times where
  not properly closed in ALTER, REPAIR or OPTIMIZE table

Other things
- Added a couple of asserts that will make it easier to
  find problems like this in the future.
2019-06-17 17:50:08 +03:00
daf333abcf Rename of stat table tried to rename open table.
When compiling with -DEXTRA_DEBUG and run main.stat_tables_missing
on go the warning:
Warning:  Table: ./mysql/column_stats is open on rename old_table

This happened because rename_table_in_stat_tables() re-open the
table that was to be renamed.
Fixed by moving update of stat tables after all renames has been made.
2019-06-17 11:20:31 +03:00
f66d1850ac Merge branch '10.3' into 10.4 2019-06-14 22:10:50 +02:00
4a3d51c76c Merge branch '10.2' into 10.3 2019-06-14 07:36:47 +02:00
4bbd8be482 Merge 10.1 into 10.2 2019-06-12 10:30:01 +03:00
be5c432a42 MDEV-16249 CHECKSUM TABLE for a spider table is not parallel and saves all data in memory in the spider head by default (#1328)
add checksum_null for setting null value of checksum
2019-06-11 00:25:08 +09:00
5a19908b95 MDEV-19653 Add class Sql_cmd_create_table 2019-05-31 16:22:53 +04:00
fae1319450 MDEV-19524 Server crashes in Bitmap<64u>::is_clear_all / Field_longstr::csinfo_change_allows_instant_alter
compare_keys_but_name(): reorder checks to ensure that
new_field->field != NULL inside Field::is_equal()
2019-05-21 08:09:19 +04:00
c07325f932 Merge branch '10.3' into 10.4 2019-05-19 20:55:37 +02:00
be85d3e61b Merge 10.2 into 10.3 2019-05-14 17:18:46 +03:00
26a14ee130 Merge 10.1 into 10.2 2019-05-13 17:54:04 +03:00
c51f85f882 Merge branch '10.2' into 10.3 2019-05-12 17:20:23 +02:00
cb248f8806 Merge branch '5.5' into 10.1 2019-05-11 22:19:05 +03:00
5543b75550 Update FSF Address
* Update wrong zip-code
2019-05-11 21:29:06 +03:00
b2f3755c8e Merge 10.1 into 10.2 2019-05-10 08:02:21 +03:00
d0b73fb8d3 MDEV-16060 - InnoDB: Failing assertion: ut_strcmp(index->name, key->name)
A sequel to 9180e86 and 149b754.

ALTER TABLE ... ADD FOREIGN KEY may crash if parent table is updated
concurrently.

Block FK parent table updates even earlier, before intermediate child
table is created.

Use proper charset info for my_casedn_str() and don't update original
identifiers so that lower_cast_table_names == 2 is honoured.
2019-05-09 11:13:44 +04:00
ffb83ba650 cleanup: move checksum code to handler class
make live checksum to be returned in handler::info(),
and slow table-scan checksum to be calculated in handler::checksum().

part of
MDEV-16249 CHECKSUM TABLE for a spider table is not parallel and saves all data in memory in the spider head by default
2019-05-07 18:40:36 +02:00
edd1a53a55 Merge 10.3 into 10.4 2019-04-08 22:00:07 +03:00
9ba0865b87 Merge 10.2 into 10.3 2019-04-08 21:38:13 +03:00
5023e465a9 copy-paste error fixed
thanks @FaramosCZ
2019-04-07 15:49:30 +02:00
3a3d5ba235 MDEV-13301 Optimize DROP INDEX, ADD INDEX into RENAME INDEX
Just rename index in data dictionary and in InnoDB cache when it's possible.
Introduce ALTER_INDEX_RENAME for that purpose so that engines can optimize
such operation.

Unused code between macro MYSQL_RENAME_INDEX was removed.

compare_keys_but_name(): compare index definitions except for index names

Alter_inplace_info::rename_keys:
ha_innobase_inplace_ctx::rename_keys: vector of rename indexes

fill_alter_inplace_info():: fills Alter_inplace_info::rename_keys
2019-04-03 18:36:33 +02:00
5d8ca98997 Get rid of rea_create_table()
Moved rea_create_table() to the sole caller.

Also ha_create_partitioning_metadata(CHF_CREATE_FLAG) does cleanup on
error now.

Part of MDEV-17805 - Remove InnoDB cache for temporary tables.
2019-04-03 17:43:12 +04:00