- developers - lists.mariadb.org

Re: [Maria-developers] Google Code for Encryption of MariaDB
by Elmar Eperiesi-Beck 09 Jun '14

09 Jun '14

Hi, 1. what about an NDA between us, to give me the chance to have a pre-view. I will make sure, that your architecture and development fits into our work. Everything we can think of in an early stage does not make lot of work, but… 2. like. 3. We will post our concept next week into the MariaDB Developers community. 4. … or 1. Regards Elmar Am 09.06.2014 um 11:14 schrieb Jonas Oreland : > Hi there, > > 1) repo: as I said in my mail, the code is currently not yet published, > but the guy doing this said that he expects it to be with in a couple of weeks or so. > before this, i don't think you can see it. > > once it's published, I think you can find it at https://code.google.com, > but I'll check and let you know. > > 2) This is my personal email address, so I prefer if we keep the conversation > @maria-developers where I'm subscribed with work email address, if this is ok > by you ? > > 3) concept paper: sure > > 4) we don't really have a concept paper, but the code is complete and being rolled out. > I can answer questions about it, but I think it's easiest once it has been published. > > /Jonas > > > > On Mon, Jun 9, 2014 at 11:02 AM, Elmar Eperiesi-Beck wrote: > Jonas, > is there a repository, where I can find the actual source code of your encryption implementation? > Or do we have to sign an NDA to exchange these kind of information? > > We can have a look at your code and merge it with our existing implementation. > Additionally I would like to send you our concept paper, to give you an overview of our ideas. > > Regards > Elmar >

1 0

[Maria-developers] [GSoC] Week 3!
by sriram patil 09 Jun '14

09 Jun '14

Hi all, Here is my post for the 3rd week into GSoC project. http://goo.gl/bhl5ZW Suggestions and review are welcome! Thanks, Sriram

1 0

[Maria-developers] MariaDB 5.5.38 Release Prep
by Daniel Bartholomew 07 Jun '14

07 Jun '14

All, I've begun prep work on the MariaDB 5.5.38 release. Draft release notes and changelog are here: - https://mariadb.com/kb/en/mariadb-5538-release-notes/ - https://mariadb.com/kb/en/mariadb-5538-changelog/ Current plan is to activate and announce the release on Mon, 9 jun 2014. Thanks. -- Daniel Bartholomew, MariaDB Release Manager MariaDB | http://mariadb.com

1 0

[Maria-developers] MDEV-5533 - Backport Threadpool improvements from Percona Server
by Sergey Vojtovich 04 Jun '14

04 Jun '14

Hi Sergei, Since MDEV-5533 is marked critical for 10.0.12 it is a good time to start this discussion. IIRC we agreed that our intention is to accept default value change for thread_pool_max_threads into 10.0 and accept priority queue throttling into 10.1. So default value for thread_pool_max_threads has bumped in percona server from 500 to 100 000. The reason is: deadlocks and uneven distribution of worker threads between thread groups in case of stalled connections. But the above is contradicting to suggestions in KB: https://mariadb.com/kb/en/threadpool-in-55/ ... so ideally, there should be a single active thread for each CPU on the machine. ... If your application constantly pegs at 500 threads, it might be a strong indicator for high contention in the application, and threadpool does not help much. ... One way to solve the problem would be to set thread_pool_max_threads to a very high value, but this might be less than ideal, and negatively affect performance. ... Said the above, do you still think it is a good idea to raise default value of thread_pool_max_threads? If so, what should KB article state wrt this variable? Thanks, Sergey

1 0

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