- developers - lists.mariadb.org

Re: [Maria-developers] [Commits] Rev 3276: Fix MySQL BUG#12329653 in file:///home/tsk/mprog/src/5.3/
by Oleksandr Byelkin 12 Nov '11

12 Nov '11

Hi! 12 нояб. 2011, в 10:24, <timour(a)askmonty.org> написал(а): The patch is OK to push after one small change: > At file:///home/tsk/mprog/src/5.3/ > > ------------------------------------------------------------ > revno: 3276 > revision-id: timour(a)askmonty.org-20111112082415-7t6jjzdfg35la7aq > parent: igor(a)askmonty.org-20111111225326-k11e0durn6kvivly > committer: timour(a)askmonty.org > branch nick: 5.3 > timestamp: Sat 2011-11-12 10:24:15 +0200 > message: > Fix MySQL BUG#12329653 > > In MariaDB, when running in ONLY_FULL_GROUP_BY mode, > the server produced in incorrect error message that there > is an aggregate function without GROUP BY, for artificially > created MIN/MAX functions during subquery MIN/MAX optimization. > > The fix introduces a way to distinguish between artifially > created MIN/MAX functions as a result of a rewrite, and normal > ones present in the query. The test for ONLY_FULL_GROUP_BY violation > now tests in addition if a MIN/MAX function was part of a MIN/MAX > subquery rewrite. > > In order to be able to distinguish these MIN/MAX functions, the > patch introduces an additional flag in Item_in_subselect::in_strategy - > SUBS_STRATEGY_CHOSEN. This flag is set when the optimizer makes its > final choice of a subuqery strategy. In order to make the choice > consistent, access to Item_in_subselect::in_strategy is provided > via new class methods. > ****** > Fix MySQL BUG#12329653 > > In MariaDB, when running in ONLY_FULL_GROUP_BY mode, > the server produced in incorrect error message that there > is an aggregate function without GROUP BY, for artificially > created MIN/MAX functions during subquery MIN/MAX optimization. > > The fix introduces a way to distinguish between artifially > created MIN/MAX functions as a result of a rewrite, and normal > ones present in the query. The test for ONLY_FULL_GROUP_BY violation > now tests in addition if a MIN/MAX function was part of a MIN/MAX > subquery rewrite. > > In order to be able to distinguish these MIN/MAX functions, the > patch introduces an additional flag in Item_in_subselect::in_strategy - > SUBS_STRATEGY_CHOSEN. This flag is set when the optimizer makes its > final choice of a subuqery strategy. In order to make the choice > consistent, access to Item_in_subselect::in_strategy is provided > via new class methods. > [skip] > @@ -2606,9 +2606,8 @@ bool > Item_allany_subselect::select_transformer(JOIN *join) > { > DBUG_ENTER("Item_allany_subselect::select_transformer"); > - DBUG_ASSERT((in_strategy & ~(SUBS_MAXMIN_INJECTED | SUBS_MAXMIN_ENGINE | > - SUBS_IN_TO_EXISTS)) == 0); > - in_strategy|= SUBS_IN_TO_EXISTS; > +// DBUG_ASSERT((in_strategy & ~(SUBS_MAXMIN_INJECTED | SUBS_MAXMIN_ENGINE | > +// SUBS_IN_TO_EXISTS)) == 0); > if (upper_item) > upper_item->show= 1; > DBUG_RETURN(select_in_like_transformer(join)); > @@ -2617,7 +2616,7 @@ Item_allany_subselect::select_transforme Remove the comment, but better change it to: DBUG_ASSERT((in_strategy & ~(SUBS_MAXMIN_INJECTED | SUBS_MAXMIN_ENGINE | SUBS_IN_TO_EXISTS | SUBS_STRATEGY_CHOSEN)) == 0); [skip]

1 0

[Maria-developers] Shared plugin library build question
by Steve Ellcey 12 Nov '11

12 Nov '11

I am looking at a difference in the HP-UX vs. Linux mariadb build and was wondering if someone could help me understand why something is set up the way it is. The problem I see is that on HP-UX, when I do a mariadb build I do not get shared plugin libraries like ha_federated. Looking into why this was happening I found that when the plugin libraries like ha_federated are built they have a dependency on libsqlservices and libsqlservices is built only as an archive library. HP-UX doesn't support building shared libaries that depend on archive libraries and so the build of the shared plugin libraries fails when no shared version of libsqlservices is found. So my main question is: why is libsqlservices built only as an archive library? The other question is: if libsqlservices has to be an archive only library, is there is another way to link it in to executables, such as linking it in explicitly when building an executable instead of counting on the shared plugin libraries to bring it in indirectly by making it a dependent library? Steve Ellcey sje(a)cup.hp.com

3 29

Re: [Maria-developers] Shared plugin library build question
by Sergei Golubchik 09 Nov '11

09 Nov '11

Hi, Michael! On Nov 09, Michael Widenius wrote: > > Hi! > > >>>>> "Vladislav" == Vladislav Vaintroub <wlad(a)montyprogram.com> writes: > > <cut> > > > I think the best option for MySQL, and for MariaDB is to rename own base64.h and function prototypes in a way that it does not conflict with system headers on any system it is meant to be run on. Relying on the include order is fragile, I also do not see how it would not solve the problem with same function name different prototypes - how can we always reliably force use our base64_encode rather than system one ? > > Yes, we should rename it to my_base64.h in MySQL 5.5 > > Serg, can you do that for your next push to 5.5? Yes, but this is just one of the problems that was mentioned in this thread. I'll wait till the list is complete and 5.5 compiles. Regards, Sergei

1 0

[Maria-developers] FYI: @@optimizer_switch default changed to have semijoin switched ON.
by Sergei Petrunia 08 Nov '11

08 Nov '11

Hi! If you haven't noticed: last week I've pushed a change that enabled semi-join optimization flags by default, i.e. now the default @@optimizer_swich value has: semijoin=on firstmatch=on loosescan=on Philip: if you have any testing planned for "after semi-join optimizations are enabled by default", now it's time to do them. BR Sergei -- Sergei Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

3 2

[Maria-developers] Bug in ENUM options handling?
by Steve Ellcey 04 Nov '11

04 Nov '11

While working on MariaDB on HP-UX we noticed an inconsistency involving the type of enum arguments. In init_variables and init_one_value (mysys/my_getopt.c), ENUM options are treated as unsigned longs but the enum arguments are actually declared as uint instead of ulong. While this doesn't matter in 32 bit mode when int's and longs's are the same size, it can cause problems in 64 bit mode when long's are 64 bits and int's 32 bits. We found 4 variables that we think should be ulong instead of uint: plugin_maturity plugin_maturity_map thread_handling delay_key_write_options We also changed the value field in the sys_var_enum class (sql/set_var.h) from a uint pointer to a ulong pointer and changed the sys_var_enum and sys_var_enum_const constructors to use a ulong pointer argument for value_arg to make everything consistent. I suppose init_variables and init_one_value could be changed to treat ENUM's as uint instead of ulong but the use of ulong seemed to be intentional so we didn't try making that change as an alternative fix. Is this a change that should be made in the official MariaDB sources? Steve Ellcey sje(a)cup.hp.com

5 8

[Maria-developers] review: [Commits] Rev 3045: Fix gcc 4.6 warning after merge with 5.1 in file:///home/bell/maria/bzr/work-maria-5.2-merge/
by Michael Widenius 04 Nov '11

04 Nov '11

Hi! Review follows: > Fix gcc 4.6 warning after merge with 5.1 > === modified file 'sql/table.cc' > --- a/sql/table.cc 2011-09-01 18:18:29 +0000 > +++ b/sql/table.cc 2011-10-27 16:18:25 +0000 > @@ -5484,7 +5484,7 @@ int update_virtual_fields(THD *thd, TABL > { > DBUG_ENTER("update_virtual_fields"); > Field **vfield_ptr, *vfield; > - int error= 0; > + int error __attribute__ ((unused))= 0; > if (!table || !table->vfield) > DBUG_RETURN(0); The above is wrong. The bug is that we ignore the value of error later down: error= vfield->vcol_info->expr_item->save_in_field(vfield, 0); We should change the above code to be: if (!ignore_errors && error < 0) { my_printf_error(ER_UNKNOWN_ERROR, "Got error when computing value for virtual column %s", vfield->field_name, MYF(0)); DBUG_RETURN(1); } We also need to add 'ignore_errors' as a parameter and add the new parameter to the calls. This can for now be '0' for all cases except for the cases where we check the value for the function, like in fill_record where we already handle the ignore_errors variable. Regards, Monty

1 0

[Maria-developers] Ubuntu 11.10 "Oneiric" packages
by Kristian Nielsen 02 Nov '11

02 Nov '11

Hi Daniel, I believe I've fixed the issues for our .debs on Ubuntu 11.10. I made buildbot create packages for MariaDB 5.2.9. They pass the tests. Buildnumber: 1325 Location in archive: /archive/pack/5.2/build-1325/kvm-deb-oneiric-* Maybe you can make them available alongside the existing 5.2.9 packages? It is the exact code version as the other platforms, but the packaging scripts are modified of course. There is no apparmor profile by default (this kept causing new problems, and future packages on Ubuntu will have it disabled by default). Maybe you can help test them as an extra check on top of the automatic ones in buildbot? I also tried getting 5.3 packages built, but Buildbot kept building the latest revision rather than the 5.3.2 one. I can probably solve that somehow, but unless it is urgent I would like to just wait for the next 5.3 release, which will get Oneiric packages automatically. Note that for 5.1, we currently have a problem, as Oneiric has MySQL 5.1.58 while the MariaDB version is 5.1.55. But for the next 5.1 release we will presumably merge MySQL 5.1.58 anyway, so this will get solved and most people will want to use 5.2 anyway I think. I think that's it, let me know if you have questions or other suggestions. - Kristian.

2 4

Re: [Maria-developers] How you build the MariaDB packages for Ubuntu
by Kristian Nielsen 02 Nov '11

02 Nov '11

Marian Marinov <mm(a)yuhu.biz> writes: > I'm trying to build MariaDB packages for CentOS. > But the problem I have is that the Policy of the distro does not allow > packages that are drop-in replacements of core packages. > Meaning that I can not simply build MariaDB which will provide libmysqlclient > and mysql binaries. > > Can you share with me what is the situation over in the Debian/Ubuntu camp ? In Debian/Ubuntu, there are no "Official" MariaDB packages yet. The ones we provide do replace the standard mysql packages, which is possible since there are no policies enforced for 3rd-party repositories. It will need to be fixed eventually, of course. The normal way I think in Debian is to have MariaDB and MySQL as alternatives, just like Some versions of Ubuntu/Debian have mysql-5.0 and mysql-5.1 as alternatives (can install one or the other, but not both). It is not 100% clear to me what your situation is (I'm not much familiar with CentOS or RPM). Are you saying that the MariaDB packages you create *must* be possible to install alongside the Official CentOS packages? In that case I suppose you have little option but to run mariadb on a different port, different data directory, different socket, different binary names. It seems to be sub-optimal for users, as they would need to reconfigure anything they want to use with MariaDB away from the standard port/names in the MySQL world. Still, this is perfectly possible to do. Configure a non-standard port in your my.cnf, build and install mariadb with a different --prefix, /opt/mariadb or whatever. - Kristian.

3 2

Re: [Maria-developers] [Commits] Rev 3262: Fix bug lp:833702 in file:///home/tsk/mprog/src/5.3/
by Oleksandr Byelkin 01 Nov '11

01 Nov '11

Hi! 01.11.2011 18:19, timour(a)askmonty.org пишет: > At file:///home/tsk/mprog/src/5.3/ > > ------------------------------------------------------------ > revno: 3262 > revision-id: timour(a)askmonty.org-20111101161919-hukh3tipjms3lfzf > parent: sanja(a)askmonty.org-20111101112209-n4ghsy9hpliiassm > fixes bug(s): https://launchpad.net/bugs/833702 > committer: timour(a)askmonty.org > branch nick: 5.3 > timestamp: Tue 2011-11-01 18:19:19 +0200 > message: > Fix bug lp:833702 > > Analysis: > Equality propagation propagated the constant '7' into > args[0] of the Item_in_optimizer that stands for the > "< ANY" predicate. At the same the min/max subquery > rewrite swapped the order of the left and right operands > of the "<" predicate, but used Item_in_subselect::left_expr. > > As a result, when the<ANY predicate is executed early in the > execution phase as a contant condition, instead of a constant > right (swapped) argument of the< predicate, there was a field > (t3.a). This field had no data, since the whole predicate is > considered constant, and it is evaluated before any tables are > read. Having junk in the field row buffer produced wrong result > > Solution: > Fix create_swap to pick the correct Item_in_optimizer left > argument. OK to push.

1 0

[Maria-developers] MariaDB test question (main.cast)
by sje＠cup.hp.com 28 Oct '11

28 Oct '11

I have downloaded, built and tested MariaDB 5.3.2 Beta on HP-UX 11.31 and I get two test failures, I have a question about one of tests that I was hoping someone could help me with. The main.cast test fails and the problem is with this part of the test: select cast(cast(20010203101112.1 as double) as datetime(1)); It is converting the string "20010203101112.1" to a double value and then converting the double value to a date. The test expects "2001-02-03 10:11:12.1" to be output but I am getting "2001-02-03 10:11:12.0". I think the problem is with the conversion into floating point. When I use gdb to break sql at double_to_datetime, on HP-UX the value I have is 20010203101112.098, on Linux I see 20010203101112.102. Neither value is completely correct because 20010203101112.1 cannot be represented exactly as an IEEE floating point value. So I have two questions. Where did the string get converted into a floating point value? I couldn't find where this is happening, I assume it is using strtod or something but breaking on that function didn't do anything. Secondly, given that 20010203101112.1 cannot be represented exactly as a double precision floating point value, is this a valid test? FYI: The other failure I get is main.cast, this test is trying to check for a stack overflow before it happens but IA64 HP-UX has two stacks, a register stack and a user data stack. In this test case the recursion of p_ere and p_ere_exp wind up using only the register stack because all the local variables and arguments are stored in registers. The stack check in check_stack_overrun is checking the user stack which doesn't overflow (or even change) and so we eventually die with a register stack overflow. There is a way to check the register stack on IA64 HP-UX, but it would require using IA64 assembly language so it may not be worth doing. Steve Ellcey sje(a)cup.hp.com

3 4