From 94946c680762954a5b88ea46b93e3975995cf504 Mon Sep 17 00:00:00 2001 From: Sven Sandberg Date: Wed, 13 Jan 2010 10:00:03 +0100 Subject: BUG#49222: Mark RAND() as unsafe Problem: When RAND() is binlogged in statement mode, the seed is binlogged too, so the replication slave generates the same sequence of random numbers. This makes replication work in many cases, but not in all cases: the order of rows is not guaranteed for, e.g., UPDATE or INSERT...SELECT statements, so the row data will be different if master and slave retrieve the rows in different orders. Fix: Mark RAND() as unsafe. It will generate a warning if binlog_format=STATEMENT and switch to row-logging if binlog_format=ROW. --- sql/item_create.cc | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'sql/item_create.cc') diff --git a/sql/item_create.cc b/sql/item_create.cc index 53aa8081da1..c309ccc06ca 100644 --- a/sql/item_create.cc +++ b/sql/item_create.cc @@ -4178,6 +4178,16 @@ Create_func_rand::create_native(THD *thd, LEX_STRING name, if (item_list != NULL) arg_count= item_list->elements; + /* + When RAND() is binlogged, the seed is binlogged too. So the + sequence of random numbers is the same on a replication slave as + on the master. However, if several RAND() values are inserted + into a table, the order in which the rows are modified may differ + between master and slave, because the order is undefined. Hence, + the statement is unsafe to log in statement format. + */ + thd->lex->set_stmt_unsafe(); + switch (arg_count) { case 0: { -- cgit v1.2.1