Sanja, I could provide some very simple binary logs (from Google MySQL 5.1) which are internally consistent and have extra headers (they would have 31-byte headers instead of the usual 19-byte ones). That can at least pretty easily be used to make sure mysqlbinlog can parse them properly. Regards, Jeremy On Thu, Jul 18, 2013 at 11:07 AM, Oleksandr Byelkin <sanja@montyprogram.com>wrote:
18.07.2013 19:39, Jeremy Cole пишет:
Sanja,
Re: https://mariadb.atlassian.net/**browse/MDEV-4645<https://mariadb.atlassian.net/browse/MDEV-4645>
I saw your commit on the commits list (sorry, wasn't on the list before the mail went out, so I can't reply directly to that message).
A couple of points related to the commit:
- You seem to have an error in the get_header_len, as it's implemented
only in the base class, and you've left functions with the correct signature for it but the wrong names in the two frozen classes (they were left named has_fixed_minimal_header). This would mean the change is completely broken. :) - The change to get_header_len I think is in general fine, although it
does alter the point of the whole thing -- there is again no way to exactly identify which events have frozen headers, programmatically (i.e. you can't differentiate them from events who just "happen" to have header_len = LOG_EVENT_MINIMAL_HEADER_LEN). I think that doesn't matter for this patch, but does defeat the point of what I was trying to add. - I don't really understand why you've made the hex printing code so
complex and completely unreadable (IMHO). This is not performance-sensitive code and in my opinion should favor readability over performance. All you seem to have saved in this change is to avoid printing some static formatting characters ("#", "|", spaces, etc.) inside the loop. However, I can hardly even figure out what it's supposed to be doing now. - Additionally, you've changed the output slightly -- normally the ASCII
character section prints its ending "|" immediately after the last character; it seems now to be fixed position (leaving extra spaces before "|". This differs from the output of hexdump, and it somewhat ambiguous/confusing. - You've mixed tabs and spaces. :(
Thank you a lot for this bug-report, I saw that the test suite do not cover the bug so did not pushed the fix hoping for your response.
Test suite still highly appreciated :) (if it is possible to make it at all, I doubts)
The cause of changes was: 1) avoid double copying string (formatting characters are not really matter) and extra memory allocation on the stack. 2) avoid 'if' in case when method can return value which we can use directly (looks better IMHO) 3) avoid extra virtual method call (they are quite expensive) Yes 1 and 3 are about performance but I deal with server code mostly.
I'll change the patch, thank you yet another time.