database/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-12-24 11:21:21 +03:00
Code Activity

BUG#51894 Replication failure with SBR on DROP TEMPORARY TABLE inside a

Browse Source 
transaction
BUG#52616 Temp table prevents switch binlog format from STATEMENT to ROW

Before the WL#2687 and BUG#46364, every non-transactional change that happened
after a transactional change was written to trx-cache and flushed upon
committing the transaction. WL#2687 and BUG#46364 changed this behavior and
non-transactional changes are now written to the binary log upon committing
the statement.

A binary log event is identified as transactional or non-transactional through
a flag in the Log_event which is set taking into account the underlie storage
engine on what it is stems from. In the current bug, this flag was not being
set properly when the DROP TEMPORARY TABLE was executed.

However, while fixing this bug we figured out that changes to temporary tables
should be always written to the trx-cache if there is an on-going transaction.
Otherwise, binlog events in the reversed order would be produced.

Regarding concurrency, keeping changes to temporary tables in the trx-cache is
also safe as temporary tables are only visible to the owner connection.

In this patch, we classify the following statements as unsafe:
   1 - INSERT INTO t_myisam SELECT * FROM t_myisam_temp

   2 - INSERT INTO t_myisam_temp SELECT * FROM t_myisam

   3 - CREATE TEMPORARY TABLE t_myisam_temp SELECT * FROM t_myisam

On the other hand, the following statements are classified as safe:

   1 - INSERT INTO t_innodb SELECT * FROM t_myisam_temp

   2 - INSERT INTO t_myisam_temp SELECT * FROM t_innodb

The patch also guarantees that transactions that have a DROP TEMPORARY are
always written to the binary log regardless of the mode and the outcome:
commit or rollback. In particular, the DROP TEMPORARY is extended with the
IF EXISTS clause when the current statement logging format is set to row.

Finally, the patch allows to switch from STATEMENT to MIXED/ROW when there
are temporary tables but the contrary is not possible.
This commit is contained in:
Alfranio Correia
2010-04-20 10:10:43 +01:00
parent 4ca8066fa9
commit 9ba731c299
52 changed files with 1060 additions and 592 deletions
Download Patch File Download Diff File Expand all files Collapse all files

77
sql/sql_class.cc
View File

@@ -3661,19 +3661,80 @@ int THD::decide_logging_format(TABLE_LIST *tables)
if (prev_write_table && prev_write_table->file->ht !=
table->table->file->ht)
multi_write_engine= TRUE;
/*
Every temporary table must be always written to the binary
log in transaction boundaries and as such we artificially
classify them as transactional.
Indirectly, this avoids classifying a temporary table created
on a non-transactional engine as unsafe when it is modified
after any transactional table:
BEGIN;
INSERT INTO innodb_t VALUES (1);
INSERT INTO myisam_t_temp VALUES (1);
COMMIT;
BINARY LOG:
BEGIN;
INSERT INTO innodb_t VALUES (1);
INSERT INTO myisam_t_temp VALUES (1);
COMMIT;
*/
all_trans_write_engines= all_trans_write_engines &&
table->table->file->has_transactions();
(table->table->file->has_transactions() ||
table->table->s->tmp_table);
prev_write_table= table->table;
flags_write_all_set &= flags;
flags_write_some_set |= flags;
}
flags_some_set |= flags;
if (prev_access_table && prev_access_table->file->ht != table->table->file->ht)
/*
The mixture of non-transactional and transactional tables must
identified and classified as unsafe. However, a temporary table
must be always handled as a transactional table. Based on that,
we have the following statements classified as mixed and by
consequence as unsafe:
1: INSERT INTO myisam_t SELECT * FROM innodb_t;
2: INSERT INTO innodb_t SELECT * FROM myisam_t;
3: INSERT INTO myisam_t SELECT * FROM myisam_t_temp;
4: INSERT INTO myisam_t_temp SELECT * FROM myisam_t;
5: CREATE TEMPORARY TABLE myisam_t_temp SELECT * FROM mysiam_t;
The following statements are not considered mixed and as such
are safe:
1: INSERT INTO innodb_t SELECT * FROM myisam_t_temp;
2: INSERT INTO myisam_t_temp SELECT * FROM innodb_t_temp;
*/
if (!trans_non_trans_access_engines && prev_access_table &&
(lex->sql_command != SQLCOM_CREATE_TABLE ||
(lex->sql_command == SQLCOM_CREATE_TABLE &&
(lex->create_info.options & HA_LEX_CREATE_TMP_TABLE))))
{
my_bool prev_trans;
my_bool act_trans;
if (prev_access_table->s->tmp_table || table->table->s->tmp_table)
{
prev_trans= prev_access_table->s->tmp_table ? TRUE :
prev_access_table->file->has_transactions();
act_trans= table->table->s->tmp_table ? TRUE :
table->table->file->has_transactions();
}
else
{
prev_trans= prev_access_table->file->has_transactions();
act_trans= table->table->file->has_transactions();
}
trans_non_trans_access_engines= (prev_trans != act_trans);
multi_access_engine= TRUE;
trans_non_trans_access_engines= trans_non_trans_access_engines ||
(prev_access_table->file->has_transactions() !=
table->table->file->has_transactions());
}
prev_access_table= table->table;
}
@@ -3710,6 +3771,12 @@ int THD::decide_logging_format(TABLE_LIST *tables)
2: INSERT INTO innodb_t SELECT * FROM myisam_t;
3: INSERT INTO myisam_t SELECT * FROM myisam_t_temp;
4: INSERT INTO myisam_t_temp SELECT * FROM myisam_t;
5: CREATE TEMPORARY TABLE myisam_t_temp SELECT * FROM mysiam_t;
are classified as unsafe to ensure that in mixed mode the execution is
completely safe and equivalent to the row mode. Consider the following
statements and sessions (connections) to understand the reason: