Martin Kaluznik <martin.kaluznik@gmail.com> writes:
Earlier you mentioned, that you are able to get my code on build server to try compile and test runs on various platforms, it would be
Ok. I have added you as a developer on https://github.com/MariaDB/server. The way it works is that you push your changes to that repository in a branch that starts with "bb-", eg. "bb-10.1-f4rnham". Then Buildbot will pick up your changes and start building (can take some hours or even a day or two in busy periods). Your builds will appear then on this page: https://buildbot.askmonty.org/buildbot/grid?branch=bb-10.1-f4rnham (Please be careful about not accidentally pushing to main branches (or any other branches) in the main repository until we've completed the review process.) Then when the builds are done, you can use the web interface to check for any failures on special platforms or test configuration, and fix them as appropriate. Meanwhile, I will read through all of your patch, and get back to you with comments.
dbug.c,my_dbug.h When line like SET GLOBAL debug_dbug="+d,flag"; is executed in test case, it acquires THR_LOCK_dbug, but when it is tested for (DBUG_EXECUTE_IF) no lock is used - and it causes data races in replication threads
Hm. The way it usually works is that the test cases SET GLOBAL debug_dbug while the slave threads are stopped. That way there should be no races? You might be right that there is a need for a lock, but I would prefer if that was made as a separate change from MDEV-7502, if possible. But it can be tricky to properly control the slave threads for testing, I will keep this point in mind when I check your test cases, and see if I can come up with concrete suggestions where needed.
Edited *.test,*.result Updated old test cases, most of them because I have added new log event type, what increased length of format description event and all positions in test cases have shifted
Right, annoying but expected. The Buildbot might catch a few more that are missed by a standard test run. - Kristian.