Re: [Maria-developers] MDEV-7502 Provisioning of slave - review
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.
Hi, Martin! On Aug 17, Kristian Nielsen wrote:
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.)
Don't worry about that. I've configured buildbot to pull changes from your https://github.com/f4rnham/server fork instead. So you can continue pushing to your forked repository. You just need to name your branches to start from "bb-" as Kristian said, if you want them tested. Regards, Sergei
On Mon, Aug 17, 2015 at 10:23 AM, Kristian Nielsen <knielsen@knielsen-hq.org> wrote:
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.
With Sergei's instructions, I have configured my fork to work with buildbot, I will continue pushing there, just to another branch https://github.com/f4rnham/server/tree/bb-10.1-f4rnham
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.
I have created all macros just for it to be consistent, that addition doesn't affect any existing code. For provisioning I need only DBUG_EXECUTE_IF_LOCKED for one flag (provisioning_wait). It is set before masters dump thread starts, but I need to remove it when the thread is running for provisioning to finish successfully. Martin
participants (3)
-
Kristian Nielsen -
Martin Kaluznik -
Sergei Golubchik