- developers - lists.mariadb.org

[Maria-developers] Your push broke windows builds on 5.3
by Sergei Petrunia 11 Oct '11

11 Oct '11

Hi Serg, Your latest push into 5.3 broke compilation on Windows: http://buildbot.askmonty.org/buildbot/builders/win2008r2-vs2010-i386-packag… http://buildbot.askmonty.org/buildbot/builders/win32-debug2/builds/734/step… Could you please fix it? (If you don't have any idea what could be the cause, maybe Wlad could help us?) BR Sergey -- Sergei Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

3 3

[Maria-developers] Preparations for 5.3.2 release
by Sergey Petrunya 10 Oct '11

10 Oct '11

Hi! As discussed on the yesterday's call, we're starting to prepare for the next 5.3 release, 5.3.2 beta. The intent is to build it on this or on the next weekend. Before the release, we need to do 1. Bugs 2. optimizer_switch changes. 3. Merge from mariadb-5.1 We don't need to address: 1. Pushing Kristian's replication features. If I heard correctly, the decision was that they won't be pushed into 5.3 (please correct me if I am wrong) == Bugs == Current situation with 5.3-targeted bugs is as follows: Crashing bugs: - SergeyP: 3 + 2 non-repeatable (#860535 #860553 #861147 #860561 (non-repeatable) #860580 (non-repeatable)) - Timour: 2 (#824425 #858148) - Nobody: 1 (#859375) Wrong query result bugs: - Timour: 8 (#858038 #817966 #833777 #825051 #826150 #747278 #833702 #856152) - Igor : 2 (#823301 #791761) - Sanja: 1 (#825075) I have a slight excuse that all my crasing bugs were filed just yesterday. I'll try to fix them before the release. Another problem area is Timour's crashes + wrong query result bugs. Also, we need to assign #859375. == optimizer_switch changes == Some of the new optimizations are already sufficiently stable so that they can be made enabled by default. >From the code quality point of view, Philip's opinion is: - subquery_cache can be turned ON. - join_cache_level can be set to value higher than 1, and also various variants of BKA/Hash join may be enabled. - MRR can be enabled - index_condition_pushdown can be enabled - Materialization still has bugs, cannot be enabled. - semi-joins+materialization cannot be enabled together, there are bugs. - semi-joins without materialization cause non-repeatable crashes, so cannot be enabled yet. - FROM subqueries/derived tables optimization didn't recieve sufficient testing yet, so cannot be enabled. Note that the above is based only on the number of known crashes/wrong query result problems, performance issues are not counted. My opinion is that - subquery_cache can be enabled. - index_condition_pushdown can be enabled. - I'm hesitant to enable MRR because it may cause slowdowns for small-dataset sysbench-like tests. - perhaps, some part of hash join could be enabled (as far as I understand, its overhead is rather small, so it doesn't cause regressions?) Anybody (and especially feature "owners") have any thoughts? == Merge from MariaDB 5.1 == Monty mentioned we'll need to do it, but nobody took this task? BR Sergey -- Sergey Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

3 2

[Maria-developers] optimizer_switch default settings change for 5.3.2: status?
by Sergey Petrunya 09 Oct '11

09 Oct '11

Hi Sanja, I was wondering if you have any progress with optimizer_switch default settings change that we decided to do for the 5.3.2 release? Any ETA on when that will be pushed? BR Sergey -- Sergey Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

1 0

[Maria-developers] 5.5 merge status
by Kristian Nielsen 07 Oct '11

07 Oct '11

Hi Serg, Here is the status of my efforts to merge the rpl,binlog, and innodb suites. These are the tests that still fail after my last pust to 5.5-serg: binlog.binlog_innodb_row This fails because of a problem in my merge of group commit, I will fix. binlog.binlog_killed I do not know yet, I can take a look next week. binlog.binlog_index This fails because of missing --test-expect-abort option which you said you would re-add back. rpl.rpl_create_if_not_exists Something with CREATE IF NOT EXISTS, I believe you said you would look at this (not related to replication). rpl.rpl_variables_stm This looks like microsecond related, maybe you can check. innodb.innodb innodb.innodb_no_mrricp innodb.innodb_mysql I think we should ask someone from optimiser to take a look at these. - Kristian.

3 3

[Maria-developers] Out of semi-join bugs, time for another testing?
by Sergey Petrunya 06 Oct '11

06 Oct '11

Hi Philip, I've fixed/pushed all semi-join bugs. If I recall correctly, you intended to do more semi-join testing, now everything is ready for it. BR Sergey -- Sergey Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

2 1

Re: [Maria-developers] MySQL Bug 59449 - Accepted by MariaDB?
by Jeremy Thomerson 05 Oct '11

05 Oct '11

Cool, thank you! As I'm not very familiar with the working process between MariaDB and MySQL upstream, do you think this patch will go back upstream? My intention in my original work on it was to get a fix into all distros that track MySQL. Thanks again! Jeremy Thomerson On Wed, Oct 5, 2011 at 8:56 AM, Timour Katchaounov <timour(a)montyprogram.com>wrote: > Hello Jeremy, > > This is to inform you that I started working on > MySQL Bug 59449. In order to track the bug progress > I created a bug in Launchpad: > https://bugs.launchpad.net/**maria/+bug/861763<https://bugs.launchpad.net/maria/+bug/861763> > > If you are interested in following the progress of > this work, please subscribe to the Launchpad bug above. > > I will work on implementing the generic solution > suggested by Monty. > > Timour > > > >> Hi! >> >> "Jeremy" == Jeremy Thomerson<jeremy(a)**thomersonfamily.com<jeremy(a)thomersonfamily.com>> >>>>>>> writes: >>>>>>> >>>>>> >> Jeremy> Monty, et al... >> Jeremy> On Mon, Jun 13, 2011 at 9:36 AM, Michael Widenius< >> monty(a)askmonty.org>**wrote: >> >> >>>> Hi! >>>> >>>> "Sergei" == Sergei Golubchik<serg(a)askmonty.org> writes: >>>>>>>>> >>>>>>>> >>>> Sergei> Hi, Jeremy! >> Sergei> On Jun 10, Jeremy Thomerson wrote: >> >>> I just submitted a patch to a MySQL bug that I am also experiencing. I >>>>>> would like to see it accepted into the wider community (MySQL, >>>>>> MariaDB, >>>>>> Percona, etc). Please let me know what I need to do so that this >>>>>> patch >>>>>> could also be accepted into your project. >>>>>> >>>>>> The bug is here: http://bugs.mysql.com/bug.php?**id=59449<http://bugs.mysql.com/bug.php?id=59449> >>>>>> The "[11 Jun 3:16] Jeremy Thomerson" comment will be the most useful. >>>>>> >>>>> >>>> >> >> Sergei> But if Oracle will refuse to fix this bug, we will look at your >> >>> patch, >>>> >>> Sergei> certainly. >> >>> >>>> To ensure we don't forget about this, if you are not sure that Oracle >>>> has fixed the bug within one month, ping us and we will look at >>>> adding this into MariaDB at once. >>>> >>>> >> Jeremy> Thanks a bunch! I was away a lot in July and August and didn't >> get to >> Jeremy> follow up on this. Looking at the original bug report, I have >> seen >> Jeremy> absolutely no activity. I'm not even sure why they have not >> touched / >> Jeremy> accepted it. If anyone here knows a way to get it into one (or >> both) >> Jeremy> projects, I'd appreciate any help you can offer. >> >> The patch you suggested was: >> >> === modified file 'sql/sql_base.cc' >> --- sql/sql_base.cc 2011-04-12 10:59:59 +0000 >> +++ sql/sql_base.cc 2011-06-10 20:11:52 +0000 >> @@ -6975,6 +6975,28 @@ >> *counter= i; >> *resolution= RESOLVED_IGNORING_ALIAS; >> break; >> + } >> + else if (find->type() == Item::FUNC_ITEM&& ((Item_func*) >> find)->functype() == Item_func::COLLATE_FUNC&& ((Item_func*) >> find)->arg_count == 2) >> >> + { >> + /* >> + If someone uses "ORDER BY column_name COLLATE utf8_spanish_ci", >> it is a function >> + that we are trying to find, and not a real column. Bug #59449 >> exposes that this >> + failed when column_name is actually referring to the name of an >> alias, whether >> + that alias is for a real column or for a function result (such >> as coalesce). This >> + block of code finds the real item, which is the "column" >> referred to by the >> + collation function for this scenario. >> + */ >> + Item *collated_column = ((Item_func*) find)->arguments()[0]; >> + int is_alias = item->type() == Item::FUNC_ITEM || >> + ((item->type() == Item::FIELD_ITEM || item->type() >> == Item::REF_ITEM)&& >> + my_strcasecmp(system_charset_**info, >> ((Item_ident*) item)->field_name, item->name)); >> + if (is_alias&& collated_column->name&& item->name&& >> !my_strcasecmp(system_charset_**info, item->name, >> collated_column->name)) >> >> + { >> + found =&collated_column; >> + *counter = i; >> + *resolution = RESOLVED_BEHIND_ALIAS; >> + break; >> + } >> } >> } >> else if (table_name&& item->type() == Item::REF_ITEM&& >> >> What I don't like with the patch is that we make COLLATE a special >> case. I think that all usage of alias names in ORDER BY should be >> treated the same. >> >> In other words: >> >> ORDER BY LanguageName >> ORDER BY LanguageName COLLATE utf8_spanish_ci >> ORDER BY concat(LanguageName,"aa") >> >> should all use either the column or the alias in the same manner. >> >> As we normally prefer alias for a column name in the ORDER BY, >> I think we should fix this so that we always prefer the alias name in >> all ORDER BY context. >> >> The other option would be to give an error in this case as it's not >> clear what the user wants. This is hower likely to break many old >> applictions. >> >> After talking with Sergei, he concluded: >> >> "yes, I believe now that according to the SQL:2003 (ISO/IEC >> 9075-2:2003, part 2 (foundations), 14.1<declare cursor>, Syntax >> Rules, item 18) aliases from the select list take precedence over >> column names from the table" >> >> The standard is very vague in the area, but it seams to support the >> idea that alias'es should resolve first). >> >> This means that we should fix things to always first prefer alias. >> The fix in this case needs to be done in item::fix_fields() and not in >> sql_base.cc >> >> I will ask Timour to see if he can provide a fix for this. >> (As he knows the fix_fields code quite well and he needs something to >> bite into now when he is back from his vacation). >> >> Timour, can you handle this? >> >> Regards, >> Monty >> >

1 0

[Maria-developers] WL#240 New (by Mdcallag): client-side compressed types
by worklog-noreply＠askmonty.org 03 Oct '11

03 Oct '11

----------------------------------------------------------------------- WORKLOG TASK -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- TASK...........: client-side compressed types CREATION DATE..: Fri, 30 Sep 2011, 20:31 SUPERVISOR.....: IMPLEMENTOR....: COPIES TO......: CATEGORY.......: Client-BackLog TASK ID........: 240 (http://askmonty.org/worklog/?tid=240) VERSION........: WorkLog-4.0 STATUS.........: Un-Assigned PRIORITY.......: 60 WORKED HOURS...: 0 ESTIMATE.......: 0 (hours remain) ORIG. ESTIMATE.: 0 PROGRESS NOTES: DESCRIPTION: Is it possible to add a variant of the blob types that is compressed on the client side? By this I mean that the client library handles compression and decompression so that the client code does not have to deal with it. The benefit from this is reduced load. There will be less network traffic between client/server and master/slave. This uses less space in the binlog, relay log, innodb transaction log and database files. The alternative is to use compression between client/server and master/slave but that doesn't help with the size of the binlog file nor with the innodb datafiles or log file. We have too many cases where huge text/blob values store uncompressed JSON and the bloat from that hurts performance. ESTIMATED WORK TIME ESTIMATED COMPLETION DATE ----------------------------------------------------------------------- WorkLog (v4.0.0)

4 4

[Maria-developers] WL#239 New (by Jaequery): ability to have multiple TIMESTAMP columns with CURRENT_TIMESTAMP / on_update TIMESTAMP
by worklog-noreply＠askmonty.org 28 Sep '11

28 Sep '11

----------------------------------------------------------------------- WORKLOG TASK -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- TASK...........: ability to have multiple TIMESTAMP columns with CURRENT_TIMESTAMP / on_update TIMESTAMP CREATION DATE..: Wed, 28 Sep 2011, 19:37 SUPERVISOR.....: IMPLEMENTOR....: COPIES TO......: CATEGORY.......: Client-BackLog TASK ID........: 239 (http://askmonty.org/worklog/?tid=239) VERSION........: Benchmarks-3.0 STATUS.........: Un-Assigned PRIORITY.......: 60 WORKED HOURS...: 0 ESTIMATE.......: 0 (hours remain) ORIG. ESTIMATE.: 0 PROGRESS NOTES: DESCRIPTION: Let's say I have two columns: 'created' and 'updated' Currently I can only let 'created' use the CURRENT_TIMESTAMP attribute. But ideally, I'd like 'updated' to also use CURRENT_TIMESTAMP as well as on_update TIMESTAMP. This makes a lot more sense for operations like this when a developer would have 'created', 'updated', or even 'deleted', columns. Only way we can do this right now is via triggers or (shudder) setting them from the app server. I understand there would be a underlying change and would really appreciate some kind of change for this particular behavior. ESTIMATED WORK TIME ESTIMATED COMPLETION DATE ----------------------------------------------------------------------- WorkLog (v4.0.0)

1 0

Re: [Maria-developers] Please review: [Commits] Rev 3199: Fix bug lp:858148. in file:///home/tsk/mprog/src/5.3/
by Igor Babaev 28 Sep '11

28 Sep '11

OK to push. Regards, Igor. On 09/28/2011 07:23 AM, Timour Katchaounov wrote: > Hi Igor, > > Could you please review the following fix. > It is very much related to a bug you fixed: > https://bugs.launchpad.net/bugs/702301 > > Thanks, > Timour > > -------- Original Message -------- > Return-Path: <commits-bounces(a)mariadb.org> > X-Original-To: timour(a)montyprogram.com > Delivered-To: timour(a)montyprogram.com > Received: from localhost (localhost.localdomain [127.0.0.1]) by > hasky.askmonty.org (Postfix) with ESMTP id DFD38D0DCB; Wed, 28 Sep > 2011 17:20:59 +0300 (EEST) > X-Virus-Scanned: Debian amavisd-new at mail.askmonty.org > Received: from hasky.askmonty.org ([127.0.0.1]) by localhost > (mail.askmonty.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP > id lpHLfsC2eNw9; Wed, 28 Sep 2011 17:20:59 +0300 (EEST) > Received: from hasky.askmonty.org (localhost.localdomain [127.0.0.1]) > by hasky.askmonty.org (Postfix) with ESMTP id BE79DC8236; Wed, 28 Sep > 2011 17:20:59 +0300 (EEST) > Received: by hasky.askmonty.org (Postfix) id 38FC0C8234; Wed, 28 Sep > 2011 17:20:58 +0300 (EEST) > Delivered-To: commits(a)mariadb.org > Received: from localhost (localhost.localdomain [127.0.0.1]) by > hasky.askmonty.org (Postfix) with ESMTP id 31622C8236 for > <commits(a)mariadb.org>; Wed, 28 Sep 2011 17:20:58 +0300 (EEST) > X-Virus-Scanned: Debian amavisd-new at mail.askmonty.org > Received: from hasky.askmonty.org ([127.0.0.1]) by localhost > (mail.askmonty.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP > id BvGNnoY8SHUx for <commits(a)mariadb.org>; Wed, 28 Sep 2011 17:20:52 > +0300 (EEST) > Received: from localhost6.localdomain6 (unknown [212.91.171.126]) > (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No > client certificate requested) by hasky.askmonty.org (Postfix) with > ESMTPSA id 24886C8234 for <commits(a)mariadb.org>; Wed, 28 Sep 2011 > 17:20:52 +0300 (EEST) > Content-Type: multipart/mixed; > boundary="===============0198351398646356273==" > MIME-Version: 1.0 > From: <timour(a)askmonty.org> > User-Agent: bzr/2.3.4 > To: <commits(a)mariadb.org> > Message-Id: <20110928142052.24886C8234(a)hasky.askmonty.org> > Date: Wed, 28 Sep 2011 17:20:52 +0300 (EEST) > Subject: [Commits] Rev 3199: Fix bug lp:858148. in > file:///home/tsk/mprog/src/5.3/ > X-BeenThere: commits(a)mariadb.org > X-Mailman-Version: 2.1.9 > Precedence: list > Reply-To: maria-developers(a)lists.launchpad.net > List-Id: MariaDB Commits List <commits.mariadb.org> > List-Unsubscribe: > <https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits>, > <mailto:commits-request@mariadb.org?subject=unsubscribe> > List-Archive: <http://lists.askmonty.org/pipermail/commits> > List-Post: <mailto:commits@mariadb.org> > List-Help: <mailto:commits-request@mariadb.org?subject=help> > List-Subscribe: > <https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits>, > <mailto:commits-request@mariadb.org?subject=subscribe> > Sender: commits-bounces(a)mariadb.org > Errors-To: commits-bounces(a)mariadb.org > > At file:///home/tsk/mprog/src/5.3/ > > ------------------------------------------------------------ > revno: 3199 > revision-id: timour(a)askmonty.org-20110928142043-b88ob3qytbroxdks > parent: psergey(a)askmonty.org-20110928090147-izz3ebqbcrnakndu > fixes bug(s): https://launchpad.net/bugs/858148 > committer: timour(a)askmonty.org > branch nick: 5.3 > timestamp: Wed 2011-09-28 17:20:43 +0300 > message: > Fix bug lp:858148. > > Analysis: > The crash is a result of the same cause as all similar > bugs (lp:827416, lp:718763, lp:778413, lp:806943, > lp:611690). The general pattern is that some optimization > requires the evaluation of some condition (e.g. the WHERE > clause), and this condition contains a subquery, such that > the subquery itself requires a temporary table for its > execution. During the subquery execution the original > tables in the FROM clause are replaced by the temporary > table needed for the final GROUP or ORDER operation. All > this happens during optimization of the outer query. Later > when EXPLAIN is run for the subquery, explain attempts to > print the name of the tables in the FROM clause, but it > finds there a temporary table without a corresponding > TABLE_LIST object. The attempt to print the name of a > NULL table list results in a crash. > > Solution: > This patch extends the fix to bug lp:702301, and dissalows > constant substitution of aggregate functions if the filter > condition used to check MIN/MAX keys is an expensive condition.

1 0

[Maria-developers] WL#238 New (by Snabb): Implement NOW() default value for DATETIME columns
by worklog-noreply＠askmonty.org 27 Sep '11

27 Sep '11

----------------------------------------------------------------------- WORKLOG TASK -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- TASK...........: Implement NOW() default value for DATETIME columns CREATION DATE..: Tue, 27 Sep 2011, 14:05 SUPERVISOR.....: IMPLEMENTOR....: COPIES TO......: CATEGORY.......: Server-RawIdeaBin TASK ID........: 238 (http://askmonty.org/worklog/?tid=238) VERSION........: Server-9.x STATUS.........: Un-Assigned PRIORITY.......: 60 WORKED HOURS...: 0 ESTIMATE.......: 0 (hours remain) ORIG. ESTIMATE.: 0 PROGRESS NOTES: DESCRIPTION: Have a look at MySQL bug #27645: http://bugs.mysql.com/bug.php?id=27645 Currently it is possible to set the default value of a TIMESTAMP column to CURRENT_TIME but this is not possible with DATETIME columns. Looking at that bug report it looks like I am not the only one who wishes to use DATETIME columns and have a way of setting their default value to the time when the row was created. Also TIMESTAMP DEFAULT CURRENT_TIME can occur only once in a table. It should be possible to have several "DATETIME DEFAULT NOW()" columns (as this is useful for having automatically initialized created_time and modified_time columns for a row, for example). Looks like MariaDB might gain some supporters by implementing this much-wanted feature. Currently the only decent work-around is to create a trigger which populates DATETIME columns before insert. (I hope this is the proper way to file a feature request.) ESTIMATED WORK TIME ESTIMATED COMPLETION DATE ----------------------------------------------------------------------- WorkLog (v4.0.0)

1 0