Bug#56226 Table map set to 0 after altering MyISAM table

After ALTER TABLE which changed only table's metadata, row-based
binlog sometimes got corrupted since the tablemap was unexpectedly
set to 0 for subsequent updates to the same table.

ALTER TABLE which changed only table's metadata always reset
table_map_id for the table share to 0. Despite the fact that
0 is a valid value for table_map_id, this step caused problems
as it could have created situation in which we had more than
one table share with table_map_id equal 0. If more than one
table with table_map_id are 0 were updated in the same statement,
updates to these different tables were written into the same
rows event. This caused slave server to crash.

This bug happens only on 5.1. It doesn't affect 5.5+.

This patch solves this problem by ensuring that ALTER TABLE
statements which change metadata only never reset table_map_id
to 0. To do this it changes reopen_table() to correctly use
refreshed table_map_id value instead of using the old one/
resetting it.


mysql-test/suite/rpl/r/rpl_alter.result:
  Add test for BUG#56226
mysql-test/suite/rpl/t/rpl_alter.test:
  Add test for BUG#56226

1 files changed, 0 insertions, 2 deletions

diff --git a/sql/sql_base.cc b/sql/sql_base.cc
index c38526a6d0b..3766ff18293 100644
--- a/sql/sql_base.cc
+++ b/sql/sql_base.cc
@@ -3082,8 +3082,6 @@ bool reopen_table(TABLE *table)
   tmp.maybe_null=	table->maybe_null;
   tmp.status=		table->status;
 
-  tmp.s->table_map_id=  table->s->table_map_id;
-
   /* Get state */
   tmp.in_use=    	thd;
   tmp.reginfo.lock_type=table->reginfo.lock_type;