mirror of
https://github.com/MariaDB/server.git
synced 2025-01-23 23:34:34 +01:00
42f8d2f249
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 |
||
|---|---|---|
| .. | ||
| binlog | ||
| bugs | ||
| engines | ||
| federated | ||
| funcs_1 | ||
| funcs_2 | ||
| ibmdb2i | ||
| im | ||
| innodb | ||
| innodb_plugin | ||
| jp | ||
| large_tests | ||
| manual | ||
| ndb | ||
| ndb_team | ||
| parts | ||
| rpl | ||
| rpl_ndb | ||
| stress | ||
| sys_vars | ||