BUG#50018: binlog corruption when table has many columns
For tables with metadata sizes ranging from 251 to 255 the size of the event data (m_data_size) was being improperly calculated in the Table_map_log_event constructor. This was due to the fact that when writing the Table_map_log_event body (in Table_map_log_event::write_data_body) a call to net_store_length is made for packing the m_field_metadata_size. It happens that net_store_length uses *one* byte for storing m_field_metadata_size when it is smaller than 251 but *three* bytes when it exceeds that value. BUG 42749 had already pinpointed and fix this fact, but the fix was incomplete, as the calculation in the Table_map_log_event constructor considers 255 instead of 251 as the threshold to increment m_data_size by three. Thence, the window for having a mismatch between the number of bytes written and the number of bytes accounted in the event length (m_data_size) was left open for m_field_metadata_size values between 251 and 255. We fix this by changing the condition in the Table_map_log_event constructor to match the one in the net_store_length, ie, increment one byte if m_field_metadata_size < 251 and three if it exceeds this value. mysql-test/suite/rpl/r/rpl_row_tbl_metadata.result: Updated result file. mysql-test/suite/rpl/t/rpl_row_tbl_metadata.test: Changes to the original test case: added slave and moved file into the rpl suite. New test case: replicates two tables one with 250 and another with 252 metadata sizes. This exercises the usage of 1 or 3 bytes while packing the m_field_metadata_size. sql/log_event.cc: Made the m_data_size calculation for the table map log event to match the number of bytes used while packing the m_field_metadata_size value (according to net_store_length function in pack.c).
Showing
Please register or sign in to comment