- changed status to resolved
MySQL history - inactive columns cause "data size mismatch" errors
My understanding is that “inactive” columns in the MySQL history are used to handle cases where the schema changes - if the number of variables gets reduced, or the names change, the deprecated columns get marked as inactive in the _history_index
.
9d17d2f breaks this, by including the inactive columns in the expected data size. This leads to error messages of the form Event 'InactiveTest/INAC' data size mismatch: expected 24 bytes, got 16 bytes
, even though only 16 bytes should now be expected in this case. The mismatch happens every single time I write, though the subsequent errors get summarised like Event 'InactiveTest/INAC' data size mismatch count: 10, expected 24 bytes, hs_write_event() called with as few as 16 bytes
. It’s still a lot of “scary red message” noise in the message log though.
The comment in the code does not make sense to me - why should inactive columns be present in the data!? Was there an edge case that was fixed by this, but with the side-effect of breaking the normal case where inactive columns should not be included?
If I uncomment lines 2745-2746 in the first diff chunk, then mlogger behaves as I expect - I get one struct size mismatch message, the columns get activated/deactivated as appropriate, and then there are no more error messages.
I attach a trivial python frontend that changes how many variables it sends from 5 to 6 to 4 - run it for 10 seconds and see what messages mlogger produces.
Comments (2)
-
reporter -
reporter KO suggested that hs_define_event() should only return active variables. That means other pieces of code (like the one in this issue) do not need to worry about active/inactive.
I agree this is the most elegant solution, and have implemented it in
54bbc9e . I have verified that my test case behaves as expected. - Log in to comment
Fix issue
#345by only returning active variables from hs_define_event(), as suggested by KO.→ <<cset 54bbc9ed5d65>>