June 2014 - developers - lists.mariadb.org

Re: [Maria-developers] MDEV-6213: Query cache is not invalidated on cascade delete when database name contains special symbols
by Sergei Golubchik 03 Jun '14

03 Jun '14

Hi, Sanja! Please add in your revision a test case for MySQL bug#13919851 http://bazaar.launchpad.net/~mysql/mysql-server/5.6/revision/4514 and make sure that your fix doesn't break it. On May 09, sanja(a)askmonty.org wrote: > revno: 4207 > revision-id: sanja(a)askmonty.org-20140509104240-ksrk10tef5dq157z > branch nick: work-maria-10.0-MDEV-6213 > timestamp: Fri 2014-05-09 13:42:40 +0300 > message: > MDEV-6213: Query cache is not invalidated on cascade delete when > database name contains special symbols. > > Innodb should de-escape db/table names when sending them to QC Regards, Sergei

1 0

[Maria-developers] Please review a patch fixing a few MDEV-6001 blockers
by Alexander Barkov 03 Jun '14

03 Jun '14

Hi Sergei, can you please review my patch fixing a few bugs that are blockers for MDEV-6001? - MDEV-4858 Wrong results for a huge unsigned value inserted into a TIME column - MDEV-6097 Inconsistent results for CAST(int,decimal,double AS DATETIME) - MDEV-6099 Bad results for DATE_ADD(.., INTERVAL 2000000000000000000.0 SECOND) - MDEV-6100 No warning on CAST(9000000 AS TIME) - MDEV-6101 Hybrid functions do not add CURRENT_DATE when converting TIME to DATETIME - MDEV-6102 Comparison between TIME and DATETIME does not use CURRENT_DATE Thanks.

2 10

[Maria-developers] Review request[major 5.3/5.5 bug]: MDEV-4511 Assertion `scale <= precision' fails on GROUP BY TIMEDIFF with incorrect types, , Agile Board, , Export
by Alexander Barkov 03 Jun '14

03 Jun '14

Hello Sergei, A few weeks ago we fixed this bug for 10.0 by changing temporal items not to have decimals=NOT_FIXED_DEC (more MySQL-5.6 compatibility), and agreed to have a separate patch for the pre-10.0 branches. This patch is for 5.3 and 5.5 only. It back-ports the mdev-4511 tests from 10.0 as is. But it does not touch the NOT_FIXED_DEC behavior of the temporal items and fixes the problem in a different way. Greetings.

1 0

[Maria-developers] POWER interest
by Colin Charles 03 Jun '14

03 Jun '14

Hi, It seems we have a POWER8 box and soon will start doing builds on this platform Stewart Smith (currently at IBM) seems to be doing some work on MySQL 5.6 and MySQL 5.7 for POWER8 systems - there doesn't seem to be much attention being paid to MariaDB 10. Ideally, our fixes that are being picked up from Stewart or focused on POWER should be targeted at 10.1 I'm thinking (unless there's customer interest for the 10.0 series -- which may very likely be the case) So far, I've noted GIS precise has an open failure, and maybe its a great idea for Holyfoot to use the POWER8 system to start fixing it: https://mariadb.atlassian.net/browse/MDEV-4153 From MySQL bugs system we see multiple examples from Stewart's blog posts - some are InnoDB specific so we will inherit them during a merge - some aren't like mysql#72715 (character set code endianness dependent on CPU type rather than endianness of CP) https://www.flamingspork.com/blog/2014/06/03/1-million-sql-queries-per-seco… https://www.flamingspork.com/blog/2014/06/03/mysql-5-7-on-power/ Relevant stuff that we may want to look at: http://bugs.mysql.com/search.php?cmd=display&status=Active&tags=PowerPC cheers, -colin -- Colin Charles, Chief Evangelist, SkySQL - The MariaDB Company blog: http://bytebot.net/blog/| t: +6-012-204-3201 | Skype: colincharles

1 0

[Maria-developers] [GSoC] First two weeks into coding!
by sriram patil 03 Jun '14

03 Jun '14

Hi all, I have created a blog to write the details of the work that I do as part of GSoC'14. Following is the link to my first blog post explaining the details of the work that I have done during the last two weeks. http://goo.gl/PYoVZb I will be writing these blog posts every weekend from now on and will share it on the developer mailing list every Monday. Suggestions/reviews are welcome. Thanks, Sriram

2 2

[Maria-developers] Possible race condition or NULL pointer triggered by OQGraph
by Andrew McDonnell 02 Jun '14

02 Jun '14

Hi all (Cross-posted to oqgraph-developers, maria-developers) I am trying to track down a segfault apparently triggered by concurrent execution of queries through OQGraph - for context, see: https://mariadb.atlassian.net/browse/MDEV-6282 I am however a bit confused as to what is going on, because at least some of the information leads me to suspect that there could be more going on here than just a simple race condition. --Immediate Cause-- On the surface, a segfault appears to be caused in a method in sql_class.h, Statement::check_limit_rows_examined() dereferencing a NULL pointer, `lex`. The method check_limit_rows_examined() was called from sql_class.h method handler::increment_statistics() . --Analysis-- A quick inspection reveals that a NULL value for `lex` is actually perfectly valid some of the time, although I am nowhere near familiar enough with the code to really understand when or why. Specifically, `lex` is a member of the base class Statement, which is initialised to either point to THD::main_lex via a constructor , or intentionally to NULL from construction of an object Prepared_statement() (sql_prepare.cc) To my mind, if there is going to be a possibility of a pointer being NULL, then all uses of that pointer should be checking for that. I am hoping that the bug reporter can prove or otherwise my hypothesis with his particular scenario, although I am suspicious that there may be additional issues to be dealt with; it is quite possible that lex being NULL is a red herring, being caused by a race condition memory overrun elsewhere. However, I think it is still a good idea to NULL check pointers that could be set to NULL intentionally. I can submit a pull request if the following patch is agreeable: diff --git a/sql/sql_class.h b/sql/sql_class.h index 5898d9e..957acf3 100644 --- a/sql/sql_class.h +++ b/sql/sql_class.h @@ -2475,8 +2475,10 @@ public: */ void check_limit_rows_examined() { - if (++accessed_rows_and_keys > lex->limit_rows_examined_cnt) + ++accessed_rows_and_keys; + if (lex && accessed_rows_and_keys > lex->limit_rows_examined_cnt) { killed= ABORT_QUERY; + } } --Aside-- Immediately prior to the check_limit_rows_examined() call is a call to macro status_var_increment(). Comments around the macro indicate it is often likely to be called in a mutli-threaded context, but the data is such that it is possible to disable protection with the only side effect being an occasionally 'inaccurate' result. Is it possible however, that check_limit_rows_examined() is not thread-safe and should have some protection? cheers, Andrew --A

3 3

[Maria-developers] MDEV-4051 INET6_ATON() and INET6_NTOA()
by Alexander Barkov 02 Jun '14

02 Jun '14

Hello Ian, I have merged these functions from MySQL-5.6 into 10.0: INET6_ATON() INET6_NTOA() IS_IPV4() IS_IPV4_COMPAT() IS_IPV4_MAPPED() IS_IPV6() Can you please document them? The corresponding article in the MySQL manual is here: http://dev.mysql.com/doc/refman/5.6/en/miscellaneous-functions.html Thanks.

2 2