mirror of
https://github.com/MariaDB/server.git
synced 2025-01-19 21:42:35 +01:00
f8758031f3
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). |
||
|---|---|---|
| .. | ||
| r | ||
| std_data | ||
| t | ||
| combinations | ||