Re: [Maria-developers] mysql-test-run (was Re: BuildBot)
Hi everyone, As a QA engineer, I had a few thoughts I would put into the discussion as well. Please feel free to take them or leave them (or to throw them a parade and give them the key to the city) ;-) On Mon, Apr 6, 2009 at 3:17 PM, Kristian Nielsen wrote: > Michael Widenius writes: > > > To go trough the things that are wrong with mysqltest: > > In my opinion, the single biggest problem with mysqltest is that it is a > seperate program from the test suite driver mysql-test-run.pl. It's even > written in a different language (C vs. Perl), and test cases themselves are > written in a third language (the mysqltest language) + a mixture of SQL and > even some shell scripts. That's _5_ different languages in a single > application :-( > > This is a disaster for the structure of mysql-test-run. Such a large part > of > the code (and complexity) is just trying to handle communication between > the > various parts, which is really hard to do well due to different languages. > > The first step in any major improvement (in my opinion) should be to > re-implement mysqltest in Perl inside mysql-test-run.pl. But that would be > a > project of several months, not something I'm eager to start just now ... I agree that more 'moving parts' = more overhead. I can't say that I agree with re-implementing in this fashion, but now would be a good time to see how we can make things leaner / more efficient / more to-the-point (ie we can focus on using the tool to test and not 'keeping the parts in harmony') > > > > I like the philosophy behind it: Write a test in pure SQL and then > > ensure that the generated result doesn't change. It's easy enough to > > allow any developers to generate a test case. > > Yes. This is a very strong point for testing that correct results are > produced > by a query or similar. Keeping something like this is very important if > thinking about extending or replacing the test framework. > > The weakness with mysqltest / mysql-test-run is not that it does this, it > is > that it does not provide additional/separate functinality for other kinds > of > tests that do not fit this simple framework well. > I very much like the straight-up SQL-> result paradigm *for certain tests*. This is GREAT for a basic, functional suite (does SELECT work. Are INSERT DEFAULT and INSERT () interchangeable ). However, getting into more 'scenario-based' testing, there are problems - coordination between 'users' in a test, tools for greybox-manipulation (tweaking the software mechanics beyond just INPUT/OUTPUT testing), etc. It would be great to keep the simplicity for certain scenarios, but to have extensible power for more complicated tests when needed. One issue I have seen with certain proposed replacements is that they allow complex testing, but the overhead of that power results in even the most simple tests becoming a monster (the overhead of defining a test). > In particular, it's good that tests and results are different files as > > it makes it easier to understand what are wrong when you get a failure. > > I am trying to understand what precisely you have in mind here... > > One big problem with other test suites I have seen is that if you want to > debug a failure, you first have to spend a lot of time debugging and > understanding the test case code just to understand what the problem > actually > is. Getting a diff of queries run and results produced like mysqltest does > makes this step trivial (if the problem is wrong results from a query). > > Also the --record functionality for generating .result files can be really > good to ease the production of test case and also make it more likely the > developer will not be tempted to insufficiently check the results > (everything > is checked by default). It does have the big risk of not properly checking > that the committed .result is in fact correct, something I have seen more > than > once. > > This does not really have to mean using separate files. I have in mind > something like a Perl-based suite where I could do: > >query
[Maria-developers] mysql-test-run (was Re: BuildBot)
Michael Widenius writes: > To go trough the things that are wrong with mysqltest: In my opinion, the single biggest problem with mysqltest is that it is a seperate program from the test suite driver mysql-test-run.pl. It's even written in a different language (C vs. Perl), and test cases themselves are written in a third language (the mysqltest language) + a mixture of SQL and even some shell scripts. That's _5_ different languages in a single application :-( This is a disaster for the structure of mysql-test-run. Such a large part of the code (and complexity) is just trying to handle communication between the various parts, which is really hard to do well due to different languages. The first step in any major improvement (in my opinion) should be to re-implement mysqltest in Perl inside mysql-test-run.pl. But that would be a project of several months, not something I'm eager to start just now ... > I like the philosophy behind it: Write a test in pure SQL and then > ensure that the generated result doesn't change. It's easy enough to > allow any developers to generate a test case. Yes. This is a very strong point for testing that correct results are produced by a query or similar. Keeping something like this is very important if thinking about extending or replacing the test framework. The weakness with mysqltest / mysql-test-run is not that it does this, it is that it does not provide additional/separate functinality for other kinds of tests that do not fit this simple framework well. > In particular, it's good that tests and results are different files as > it makes it easier to understand what are wrong when you get a failure. I am trying to understand what precisely you have in mind here... One big problem with other test suites I have seen is that if you want to debug a failure, you first have to spend a lot of time debugging and understanding the test case code just to understand what the problem actually is. Getting a diff of queries run and results produced like mysqltest does makes this step trivial (if the problem is wrong results from a query). Also the --record functionality for generating .result files can be really good to ease the production of test case and also make it more likely the developer will not be tempted to insufficiently check the results (everything is checked by default). It does have the big risk of not properly checking that the committed .result is in fact correct, something I have seen more than once. This does not really have to mean using separate files. I have in mind something like a Perl-based suite where I could do: query < One benefit is that you can usually run a test by just piping it > trough the normal MySQL client, which simplifies testing and > debugging a lot! Yes, this should be kept for simple stuff, very important. - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Maria binary builds
Kristian, If you can share your Buildbot configuration that would be perfect! As for platforms we see demand for Debian/Ubuntu/CentOS both 32bit and 64bit. Also quite often are mentioned FreeBSD, MacOS and Windows. For CFLAGS / configure I found combination from MySQL .spec for RedHat 5 works almost fine. The changes I made for CFLAGS I am adding next combination: -O2 -g -fno-omit-frame-pointer it makes life to debugs hangs / crashes easier. Thanks! Vadim Kristian Nielsen wrote: > Hi Vadim, > > Just an update on what I have been doing with binaries and Buildbot. > > I have now set up Buildbot to build and test our trees on Launchpad after > every push (similar to Pushbuild at MySQL/Sun if you are familiar with that): > > http://askmonty.org/buildbot/index.html > > For now we have only few (one) build slave. The plan of course is to add more, > hopefully some of them volunteered from the community (hint :-). > > I would be happy to make the infrastructure available to you as well, ie. to > set it up to also track your Launcpad trees and build on your build slaves > with your scripts and options. But you may prefer to control the buildbot > master yourself; just let me know if you need a copy of my Buildbot > configuration files or if I can help with any questions in setting it up. > > I am currently working on getting all existing test failures visible in the > Buildbot runs fixed (Valgrind errors mostly). > > After that (next week I hope) I plan to turn to working on getting Buildbot to > also produce binaries. > > I will need to do some research in which platforms we need to build for > (Debian/Ubuntu/CentOS/Suse/Generic? x86/amd64? Any others?), and which > configure / build options to use. Any help you can provide here would be much > appreciated. I have lots of experience with scripting this kind of thing, but > less so with the details of how people actually use the binaries and what they > need (I have mostly build from source myself even for production). I also plan > to look at what official Debian/Ubuntu packages provide, and at the scripts > from OurDelta. > > My vision is to have production and test of binaries fully integrated into our > Buildbot infrastructure. I want it fully automated, so that binaries are made > after every push, and so that problems with the binaries are dealt with as an > integrated part of development just like any other problem. Ideally, releasing > binaries would then just be a matter of picking the right files from the > buildbot archives. It will take some work to get there of course, but at least > that is the vision. > >>From what I have seen of Buildbot so far, I am hopeful that it will be > sufficient for our needs. It seems to have all of the right ideas, and many of > the necessary features are already there. Some stuff will be missing, and my > plan is to spend the time to extend it as needed. > > So for concrete plans next week, these currently are: > > 1. Setup build of generic binaries (.tar.gz) for Linux x86/amd64. For this I > need to understand better how to deal with external dependencies. Should I > link statically with libc? My impression is not to do this as I think this > causes big problems with any type of plugin, but I also seem to recall that > existing generic packages do this. Alternatively, I need to understand which > version of glibc to use. > > 2. Work on getting build slave machines set up for this. > > 3. Get a first version running on Buildbot that produces the binaries. > > After this I think will be Debian and Ubuntu binaries with apt-able > repositories, and then RPMs. > > I think that's it for an update of current plans. Let me know if you have any > questions/comments/suggestions. Especially any help on exact CFLAGS and > ./configure arguments to use would be very helpful. > > - Kristian. > -- Vadim Tkachenko, CTO Percona Inc. ICQ: 369-510-335, Skype: vadimtk153, Phone +1-888-401-3403 MySQL Performance Blog - http://www.mysqlperformanceblog.com MySQL Consulting http://www.percona.com/ Attend the 2009 Percona Performance Conference April 22-23 - http://conferences.percona.com/ ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Merge] lp:~maria-captains/maria/maria-xtradb into lp:maria
Kristian, Uh, Thank you for looking into this. You ask good question re: INNODB_RW_LOCKS_USE_ATOMICS, this is actually one of main points of XtraDB to improve scalability on 8CPU+ boxes, so we just rely on it. XtraDB can be built without INNODB_RW_LOCKS_USE_ATOMICS, but effect may be opposite - we can see slowdown instead of improvement. I am not sure what to do with this, I also need to look into InnoDB-plugin 1.0.3, what solution they have and may be use new InnoDB rw_locks instead of ours. Anyway - this is something to discuss. About tests you should execute setup.sh from storage/innobase before running test, as it patches main test suite by InnoDB specific tests. I did not want to put them into main test suite to keep all changes only to storage/innobase repository. In our tests only two tests do not pass after patches - it is main.variables_big and main.read_many_rows_innodb, but they also do not pass in native InnoDB-plugin. Again what to do with tests it is topic to discuss, I do not see obvious way for now... Thanks! Vadim Kristian Nielsen wrote: > Percona writes: > >> Percona has proposed merging lp:~maria-captains/maria/maria-xtradb into >> lp:maria. >> >> Requested reviews: >> Maria-captains (maria-captains) >> >> Proposal to merge replacement InnoDB->XtraDB > > Thanks a lot for your efforts in this! > > I branched the tree and took a look. There are a couple of issues that I think > need to be resolved before we can merge it into MariaDB. I have some questions > below, but please don't hesitate to ask me for any kind of help needed to move > this forward. > >> === modified file 'storage/innobase/include/sync0rw.h' >> --- storage/innobase/include/sync0rw.h 2008-02-19 16:44:09 + >> +++ storage/innobase/include/sync0rw.h 2009-03-31 04:19:17 + > >> +#ifndef INNODB_RW_LOCKS_USE_ATOMICS >> +#error INNODB_RW_LOCKS_USE_ATOMICS is not defined. Do you use enough new >> GCC or compatibles? >> +#error Or do you use exact options for CFLAGS? >> +#error e.g. (for x86_32): "-m32 -march=i586 -mtune=i686" >> +#error e.g. (for Sparc_64): "-m64 -mcpu=v9" >> +#error Otherwise, this build may be slower than normal version. >> +#endif >> + > > My attempt to build (BUILD/compile-pentium64-max) failed with this > error. There were also other build errors (I assume places where the > atomics-using code has not been extended with a part that works without the > availability of atomics). > > The reason is that in the MariaDB tree, HAVE_GCC_ATOMIC_BUILTINS is disabled, > which caused XtraDB to disable INNODB_RW_LOCKS_USE_ATOMICS, which triggers the > above error. > > I think I understand why this makes sense for Percona, after all using these > better synchronisation primitives is part of the reason for using the Percona > server in the first place. > > Can you tell me if Percona has decided not to maintain XtraDB working without > the availability of atomic operations? Or if it is just an oversight? > > I need to discuss with other MariaDB people whether XtraDB for MariaDB should > be maintained working without the atomic operations (if so, we should of > course be willing to do the work/effort required). > > So, any thoughts about the best way to deal with this? Should the above #error > be removed and XtraDB extended to work without atomics in the MariaDB tree? > And is this something Percona wants to do, or should I look into it? > > Also, Sergei Golubchik told me that HAVE_GCC_ATOMIC_BUILTINS is for > my_atomic_ops, and InnoDB/XtraDB shouldn't really be using it. But I need to > look more into the code to understand what the problem is, if any. > >> === added directory 'storage/innobase/mysql-test' > >> === added directory 'storage/innobase/mysql-test/patches' > > When I ran the test suite, I got test failures in test main.innodb. > > I see that the patch contains patches for main MySQL test cases in > mysql-test/t/*.test, and also seems to add separate test cases in the > storage/innobase/mysql-test/ directory. > > Do you know what the status is of these test suite modifications? Do the > patches need to be applied to the existing test suite, and/or should the extra > test cases be used to add to/overwrite the existing tests? > > We would need to get the test suite to run without problems before > merging. Does Percona run the test suite with no failures? Can you suggest > which directions I should work in to solve the test failures? Ie. I'm unsure > to what extent the extra test cases/patches have already been applied in main > MySQL sources, and whether failures are expected or are just due to not being > adapted for current MariaDB source changes. > > Any help with the above would be great. I plan to continue working with you on > this so we can get it merged without unnecessary delays. > > - Kristian. > -- Vadim Tkachenko, CTO Percona Inc. ICQ: 369-510-335, Skype: vadimtk153, Phone +1-888-401-3403 MySQL Performance Blog - http://www.mysqlperformanc
Re: [Maria-developers] Maria binary builds
I have two idle machines, one Debian lenny x86-64 and the other alpha. How can I help by adding these to the build pool? Is there interest in alpha? -- Cheers, Adam On Apr 6, 2009, at 9:13, Kristian Nielsen wrote: Hi Vadim, Just an update on what I have been doing with binaries and Buildbot. I have now set up Buildbot to build and test our trees on Launchpad after every push (similar to Pushbuild at MySQL/Sun if you are familiar with that): http://askmonty.org/buildbot/index.html For now we have only few (one) build slave. The plan of course is to add more, hopefully some of them volunteered from the community (hint :-). I would be happy to make the infrastructure available to you as well, ie. to set it up to also track your Launcpad trees and build on your build slaves with your scripts and options. But you may prefer to control the buildbot master yourself; just let me know if you need a copy of my Buildbot configuration files or if I can help with any questions in setting it up. I am currently working on getting all existing test failures visible in the Buildbot runs fixed (Valgrind errors mostly). After that (next week I hope) I plan to turn to working on getting Buildbot to also produce binaries. I will need to do some research in which platforms we need to build for (Debian/Ubuntu/CentOS/Suse/Generic? x86/amd64? Any others?), and which configure / build options to use. Any help you can provide here would be much appreciated. I have lots of experience with scripting this kind of thing, but less so with the details of how people actually use the binaries and what they need (I have mostly build from source myself even for production). I also plan to look at what official Debian/Ubuntu packages provide, and at the scripts from OurDelta. My vision is to have production and test of binaries fully integrated into our Buildbot infrastructure. I want it fully automated, so that binaries are made after every push, and so that problems with the binaries are dealt with as an integrated part of development just like any other problem. Ideally, releasing binaries would then just be a matter of picking the right files from the buildbot archives. It will take some work to get there of course, but at least that is the vision. From what I have seen of Buildbot so far, I am hopeful that it will be sufficient for our needs. It seems to have all of the right ideas, and many of the necessary features are already there. Some stuff will be missing, and my plan is to spend the time to extend it as needed. So for concrete plans next week, these currently are: 1. Setup build of generic binaries (.tar.gz) for Linux x86/amd64. For this I need to understand better how to deal with external dependencies. Should I link statically with libc? My impression is not to do this as I think this causes big problems with any type of plugin, but I also seem to recall that existing generic packages do this. Alternatively, I need to understand which version of glibc to use. 2. Work on getting build slave machines set up for this. 3. Get a first version running on Buildbot that produces the binaries. After this I think will be Debian and Ubuntu binaries with apt-able repositories, and then RPMs. I think that's it for an update of current plans. Let me know if you have any questions/comments/suggestions. Especially any help on exact CFLAGS and ./configure arguments to use would be very helpful. - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Maria binary builds
Hi Vadim, Just an update on what I have been doing with binaries and Buildbot. I have now set up Buildbot to build and test our trees on Launchpad after every push (similar to Pushbuild at MySQL/Sun if you are familiar with that): http://askmonty.org/buildbot/index.html For now we have only few (one) build slave. The plan of course is to add more, hopefully some of them volunteered from the community (hint :-). I would be happy to make the infrastructure available to you as well, ie. to set it up to also track your Launcpad trees and build on your build slaves with your scripts and options. But you may prefer to control the buildbot master yourself; just let me know if you need a copy of my Buildbot configuration files or if I can help with any questions in setting it up. I am currently working on getting all existing test failures visible in the Buildbot runs fixed (Valgrind errors mostly). After that (next week I hope) I plan to turn to working on getting Buildbot to also produce binaries. I will need to do some research in which platforms we need to build for (Debian/Ubuntu/CentOS/Suse/Generic? x86/amd64? Any others?), and which configure / build options to use. Any help you can provide here would be much appreciated. I have lots of experience with scripting this kind of thing, but less so with the details of how people actually use the binaries and what they need (I have mostly build from source myself even for production). I also plan to look at what official Debian/Ubuntu packages provide, and at the scripts from OurDelta. My vision is to have production and test of binaries fully integrated into our Buildbot infrastructure. I want it fully automated, so that binaries are made after every push, and so that problems with the binaries are dealt with as an integrated part of development just like any other problem. Ideally, releasing binaries would then just be a matter of picking the right files from the buildbot archives. It will take some work to get there of course, but at least that is the vision. >From what I have seen of Buildbot so far, I am hopeful that it will be sufficient for our needs. It seems to have all of the right ideas, and many of the necessary features are already there. Some stuff will be missing, and my plan is to spend the time to extend it as needed. So for concrete plans next week, these currently are: 1. Setup build of generic binaries (.tar.gz) for Linux x86/amd64. For this I need to understand better how to deal with external dependencies. Should I link statically with libc? My impression is not to do this as I think this causes big problems with any type of plugin, but I also seem to recall that existing generic packages do this. Alternatively, I need to understand which version of glibc to use. 2. Work on getting build slave machines set up for this. 3. Get a first version running on Buildbot that produces the binaries. After this I think will be Debian and Ubuntu binaries with apt-able repositories, and then RPMs. I think that's it for an update of current plans. Let me know if you have any questions/comments/suggestions. Especially any help on exact CFLAGS and ./configure arguments to use would be very helpful. - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] MariaDB + PBXT
Hi Kristian, On Apr 6, 2009, at 1:17 PM, Kristian Nielsen wrote: It resulted in me, and all other captains, getting a HUGE diff in an e- mail - SORRY! Mac Mail really struggled, Yikes! Don't worry. Anyway, I found a setting on Launchpad for limiting diff sizes in emails. I changed it to max 5000 lines (from unlimited). Not 100% sure it was the right place I changed though, Launchpad can be a bit confusing sometimes. Ah, good to know. I'll give that a try as well. This branch includes the current MariaDB revision (2689) and the PBXT storage engine. The only changes are the addition of a storage/pbxt and a mysql-test/suite/pbxt directory. PBXT seems to be included in BUILD/compile-pentium64-debug-max, great! The mysql-test/suite/pbxt directory contains a test suite for PBXT. The test includes 167 test files. All tests run through without error. To run the tests use: ./mysql-test-run --mysqld=--default-storage-engine=pbxt --suite=pbxt In other words, you have to set the default storage engine to PBXT for this test to run. Testsuite did not pass without errors for me in the MariaDB tree. I saw these failures: pbxt.count_distinct2 (glibc detected double free error) pbxt.count_distinct3 (mysqld crash) pbxt.lowercase_table_grant pbxt.lowercase_table_qcache pbxt.lowercase_view pbxt.pbxt_bugs pbxt.udf The count* tests did not fail everytime I ran the tests. The *lowercase* test failures seems related to case differences. Test pbxt_bugs is missing file suite/pbxt/t/load_unique_error1.inc. The test pbxt.udf complains about missing udf_example.so (not sure why). Just let me know if you need more help/information on these failures. Yes, thanks. I would like to get these fixed. However, since the PBXT test suite is not run by default, I think we can merge it anyway now, and then work on getting these issues solved afterwards. OK I have set up Buildbot to automatically test the MariaDB code, and I need to find a build slave somewhere that could run tests of the PBXT code (feel free to offer to run one if you have a spare machine handy ;-). That would be helpful in getting a clean PBXT test run (and keeping it clean). Yes, OK. I think we can work something out. Please let me know if this is OK for merge. This is ok to push as it is. Since you are a member of maria-captains on Launchpad, you can go ahead and push the merge to lp:maria yourself. (But if you prefer, I can also pull from your tree and push the merge). OK, I will push it. [The general policy for pushing to MariaDB is that you can push yourself once you get an 'ok to push' from review. Small fixes to a broken build etc. are sometimes pushed immediately to avoid delaying other work, and then reviewed after the fact.] Yup, sounds good. Do you have a plan for merging in subsequent PBXT changes to MariaDB? (I guess you do, just don't know how it works). Would you be in charge of regular merging, or should the MariaDB team pull/merge from PBXT? Plan is to merge regularly and, of course, just before we make a release. However, we have not worked out a schedule yet. Generally we will make sure all our tests run through with MySQL before we merge into MariaDB. However, you are free to pull the latest PBXT tree and merge it into MariaDB any time you like. If you make any changes or fixes I would be glad to accept a patch for PBXT. Our goal is to keep one set of source code for all versions of MySQL supported. With PBXT both in MySQL, Drizzle, and MariaDB, the merge effort on your part could be non-trivial, so feel free to ask for help if needed. Yes, thanks. I will let you know if we need some help. Currently it is only Vlad and myself working on PBXT. Again, thanks a lot for your efforts on this! np :) Best regards, Paul - Kristian. -- Paul McCullagh PrimeBase Technologies www.primebase.org www.blobstreaming.org pbxt.blogspot.com ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] MariaDB + PBXT
Paul McCullagh writes: > I have just proposed merge of the maria-pbxt tree into lp:maria. Thanks a lot for your effort! I branched your tree locally and tested it a little bit. > It resulted in me, and all other captains, getting a HUGE diff in an > e- > mail - SORRY! Mac Mail really struggled, Yikes! Don't worry. Anyway, I found a setting on Launchpad for limiting diff sizes in emails. I changed it to max 5000 lines (from unlimited). Not 100% sure it was the right place I changed though, Launchpad can be a bit confusing sometimes. > This branch includes the current MariaDB revision (2689) and the PBXT > storage engine. The only changes are the addition of a storage/pbxt > and a mysql-test/suite/pbxt directory. PBXT seems to be included in BUILD/compile-pentium64-debug-max, great! > The mysql-test/suite/pbxt directory contains a test suite for PBXT. > The test includes 167 test files. All tests run through without error. > To run the tests use: > > ./mysql-test-run --mysqld=--default-storage-engine=pbxt --suite=pbxt > > In other words, you have to set the default storage engine to PBXT for > this test to run. Testsuite did not pass without errors for me in the MariaDB tree. I saw these failures: pbxt.count_distinct2 (glibc detected double free error) pbxt.count_distinct3 (mysqld crash) pbxt.lowercase_table_grant pbxt.lowercase_table_qcache pbxt.lowercase_view pbxt.pbxt_bugs pbxt.udf The count* tests did not fail everytime I ran the tests. The *lowercase* test failures seems related to case differences. Test pbxt_bugs is missing file suite/pbxt/t/load_unique_error1.inc. The test pbxt.udf complains about missing udf_example.so (not sure why). Just let me know if you need more help/information on these failures. However, since the PBXT test suite is not run by default, I think we can merge it anyway now, and then work on getting these issues solved afterwards. I have set up Buildbot to automatically test the MariaDB code, and I need to find a build slave somewhere that could run tests of the PBXT code (feel free to offer to run one if you have a spare machine handy ;-). That would be helpful in getting a clean PBXT test run (and keeping it clean). > PBXT only creates files when the first PBXT table is created. > > So when you start MariaDB you will only know that PBXT is installed > because of the startup message it prints in the log. It does not > create any files in the database root directory. Ok. > Please let me know if this is OK for merge. This is ok to push as it is. Since you are a member of maria-captains on Launchpad, you can go ahead and push the merge to lp:maria yourself. (But if you prefer, I can also pull from your tree and push the merge). [The general policy for pushing to MariaDB is that you can push yourself once you get an 'ok to push' from review. Small fixes to a broken build etc. are sometimes pushed immediately to avoid delaying other work, and then reviewed after the fact.] Do you have a plan for merging in subsequent PBXT changes to MariaDB? (I guess you do, just don't know how it works). Would you be in charge of regular merging, or should the MariaDB team pull/merge from PBXT? With PBXT both in MySQL, Drizzle, and MariaDB, the merge effort on your part could be non-trivial, so feel free to ask for help if needed. > Best regards, > > Paul Again, thanks a lot for your efforts on this! - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Merge] lp:~maria-captains/maria/maria-xtradb into lp:maria
Percona writes: > Percona has proposed merging lp:~maria-captains/maria/maria-xtradb into > lp:maria. > > Requested reviews: > Maria-captains (maria-captains) > > Proposal to merge replacement InnoDB->XtraDB Thanks a lot for your efforts in this! I branched the tree and took a look. There are a couple of issues that I think need to be resolved before we can merge it into MariaDB. I have some questions below, but please don't hesitate to ask me for any kind of help needed to move this forward. > === modified file 'storage/innobase/include/sync0rw.h' > --- storage/innobase/include/sync0rw.h2008-02-19 16:44:09 + > +++ storage/innobase/include/sync0rw.h2009-03-31 04:19:17 + > +#ifndef INNODB_RW_LOCKS_USE_ATOMICS > +#error INNODB_RW_LOCKS_USE_ATOMICS is not defined. Do you use enough new GCC > or compatibles? > +#error Or do you use exact options for CFLAGS? > +#error e.g. (for x86_32): "-m32 -march=i586 -mtune=i686" > +#error e.g. (for Sparc_64): "-m64 -mcpu=v9" > +#error Otherwise, this build may be slower than normal version. > +#endif > + My attempt to build (BUILD/compile-pentium64-max) failed with this error. There were also other build errors (I assume places where the atomics-using code has not been extended with a part that works without the availability of atomics). The reason is that in the MariaDB tree, HAVE_GCC_ATOMIC_BUILTINS is disabled, which caused XtraDB to disable INNODB_RW_LOCKS_USE_ATOMICS, which triggers the above error. I think I understand why this makes sense for Percona, after all using these better synchronisation primitives is part of the reason for using the Percona server in the first place. Can you tell me if Percona has decided not to maintain XtraDB working without the availability of atomic operations? Or if it is just an oversight? I need to discuss with other MariaDB people whether XtraDB for MariaDB should be maintained working without the atomic operations (if so, we should of course be willing to do the work/effort required). So, any thoughts about the best way to deal with this? Should the above #error be removed and XtraDB extended to work without atomics in the MariaDB tree? And is this something Percona wants to do, or should I look into it? Also, Sergei Golubchik told me that HAVE_GCC_ATOMIC_BUILTINS is for my_atomic_ops, and InnoDB/XtraDB shouldn't really be using it. But I need to look more into the code to understand what the problem is, if any. > === added directory 'storage/innobase/mysql-test' > === added directory 'storage/innobase/mysql-test/patches' When I ran the test suite, I got test failures in test main.innodb. I see that the patch contains patches for main MySQL test cases in mysql-test/t/*.test, and also seems to add separate test cases in the storage/innobase/mysql-test/ directory. Do you know what the status is of these test suite modifications? Do the patches need to be applied to the existing test suite, and/or should the extra test cases be used to add to/overwrite the existing tests? We would need to get the test suite to run without problems before merging. Does Percona run the test suite with no failures? Can you suggest which directions I should work in to solve the test failures? Ie. I'm unsure to what extent the extra test cases/patches have already been applied in main MySQL sources, and whether failures are expected or are just due to not being adapted for current MariaDB source changes. Any help with the above would be great. I plan to continue working with you on this so we can get it merged without unnecessary delays. - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
