1
0
mirror of https://github.com/MariaDB/server.git synced 2025-07-30 16:24:05 +03:00

BUG#34768 - nondeterministic INSERT using LIMIT logged in stmt mode if

binlog_format=mixed

Statement-based replication of DELETE ... LIMIT, UPDATE ... LIMIT,
INSERT ... SELECT ... LIMIT is not safe as order of rows is not
defined.

With this fix, we issue a warning that this statement is not safe to
replicate in statement mode, or go to row-based mode in mixed mode.

Note that we may consider a statement as safe if ORDER BY primary_key
is present. However it may confuse users to see very similiar statements
replicated differently.

Note 2: regular UPDATE statement (w/o LIMIT) is unsafe as well, but
this patch doesn't address this issue. See comment from Kristian
posted 18 Mar 10:55.
This commit is contained in:
svoj@mysql.com/june.mysql.com
2008-03-18 20:25:34 +04:00
parent bdc74bbda7
commit 6dfb184f09
6 changed files with 90 additions and 2 deletions

View File

@ -2763,6 +2763,19 @@ bool mysql_insert_select_prepare(THD *thd)
TABLE_LIST *first_select_leaf_table;
DBUG_ENTER("mysql_insert_select_prepare");
/*
Statement-based replication of INSERT ... SELECT ... LIMIT is not safe
as order of rows is not defined, so in mixed mode we go to row-based.
Note that we may consider a statement as safe if ORDER BY primary_key
is present or we SELECT a constant. However it may confuse users to
see very similiar statements replicated differently.
*/
if (lex->current_select->select_limit)
{
lex->set_stmt_unsafe();
thd->set_current_stmt_binlog_row_based_if_mixed();
}
/*
SELECT_LEX do not belong to INSERT statement, so we can't add WHERE
clause if table is VIEW