September 2011 - developers - lists.mariadb.org

[Maria-developers] WL#237 New (by DonQuichote): more IF EXISTS clauses
by worklog-noreply＠askmonty.org 23 Sep '11

23 Sep '11

----------------------------------------------------------------------- WORKLOG TASK -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- TASK...........: more IF EXISTS clauses CREATION DATE..: Fri, 23 Sep 2011, 14:10 SUPERVISOR.....: IMPLEMENTOR....: COPIES TO......: CATEGORY.......: Server-RawIdeaBin TASK ID........: 237 (http://askmonty.org/worklog/?tid=237) VERSION........: WorkLog-4.0 STATUS.........: Un-Assigned PRIORITY.......: 60 WORKED HOURS...: 0 ESTIMATE.......: 0 (hours remain) ORIG. ESTIMATE.: 0 PROGRESS NOTES: DESCRIPTION: It would be nice if more statements were repeatable for use in scripts (See http://www.howtoforge.com/node/4833 for the use of this). I would like to see the IF (NOT) EXISTS clauses added to the RENAME command and it would really be nice if such a clause could be added to the various operations of the ALTER TABLE command. For example: RENAME TABLE IF EXISTS WrongName TO RightName; -- when placed in an update script, it will rename the table if it still has the wrong name, but it will not fail if it already has the right name. ALTER TABLE SomeTable ADD COLUMN IF NOT EXISTS ExtraColumn VARCHAR(255) DEFAULT NULL; ESTIMATED WORK TIME ESTIMATED COMPLETION DATE ----------------------------------------------------------------------- WorkLog (v4.0.0)

1 0

[Maria-developers] MariaDB 5.2.9
by Daniel Bartholomew 23 Sep '11

23 Sep '11

All, Monty asked me to prep the MariaDB 5.2.9 release. He said to use the build of revision 3033 for the release: http://buildbot.askmonty.org/buildbot/grid?branch=5.2&category=package http://bazaar.launchpad.net/~maria-captains/maria/5.2/revision/3033 ...and I've uploaded the files from that build to the primary mirror. They should be mirrored worldwide by tomorrow. But before I can finish the release and announce it I need a couple of things: First, I need one of the developers to tag the release in the source tree: http://bazaar.launchpad.net/~maria-captains/maria/5.2/changes Second, I need to know if there is anything that I should be sure to mention in the release notes. One thing I can think of which hasn't been mentioned in the past few release notes is which version of MySQL that this version of MariaDB has merged in. The current versions of other things, like PBXT and XtraDB would also be helpful. Thanks. -- Daniel Bartholomew MariaDB - http://mariadb.org Monty Program - http://montyprogram.com AskMonty Knowledgebase - http://kb.askmonty.org

2 2

[Maria-developers] Building MariaDB 3.1 Beta on HP-UX
by Steve Ellcey 22 Sep '11

22 Sep '11

Hi, I have downloaded the MariaDB 3.1 Beta sources and am trying to build MariaDB on HP-UX 11.31 using the HP compilers and ran into a few problems that I wanted to ask about. The first problem I ran into was with anonymous unions (and structs). Anonymous unions are part of the C++ standard, but not C (though the GNU C compiler allows them). The header file include/ma_dyncol.h has a structure, st_dynamic_column_value, which includes both anonymous unions and anonymous structures and this file is included in both C files (mysys/ma_dyncol.c and unittest/mysys/ma_dyncol-t.c) and C++ files (sql/item_strfunc.cc). This is causing the HP C compiler problems since it doesn't allow anonymous unions (or structs) by default. Now I can use a GNU compatibility mode in the compiler (-Agcc) to allow this to compile, but that creates other problems, specifically it causes the MariaDB configure script to think I am using GCC (because __GNUC__ is defined in this mode) and then it runs the ABI check which fails because the HP compiler doesn't generate preprocessed source that exactly matches the expected GNU compiler output due to minor changes in the output. So I was wondering if this use of anonymous unions in C code was intentional or unintentional? I was also wondering about the use of the anonymous structs in the anonymous union as that is not part of the C or C++ standards, though the GNU compilers only complain about this when you use the -pedantic flag. What solution to this issue would people recommend? We could use the GNU compatibility mode with the HP compilers but would have to modify the configure script to not run the ABI check. Or we could remove the use of anonymous unions (and structs) from the C code in MariaDB. I prefer the second option because it makes the C code more consistent with the C99 standard. Steve Ellcey sje(a)cup.hp.com

2 3

[Maria-developers] MySQL Bug 59449 - Accepted by MariaDB?
by Jeremy Thomerson 21 Sep '11

21 Sep '11

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 The "[11 Jun 3:16] Jeremy Thomerson" comment will be the most useful. Please CC me on any replies to this thread because I am not subscribed to this mailing list. Best Regards, Jeremy Thomerson

3 4

[Maria-developers] Microseconds support in MariaDB 5.3.
by Peter Laursen 21 Sep '11

21 Sep '11

I noticed: http://askmonty.org/blog/the-2-year-old-mariadb/ "The support for microseconds in TIMESTAMP, DATETIME, and TIME". I fully agree the 'full seconds support only' has been a sever limitation in MySQL. But I have two concerns with ths: 1) 'noisyness'. On not very fast systems the last digits of a TIME in microseconds should not be considered too much important. It depends on what else the system is doing at the time. I think for lots of users milliseconds and not microseconds would be better/more relevant. It is not always a lot of digits can be proven true. When we went to school we were all taught not to present results in natural sciences more accurate than the accuracy of data sources and measurements. Providing too many digits in a resuslt actually caused a lower score in my highschool! 2) Compability. There is a problem with UPDATES. A client/application written for MySQL may assume 'full seconds support only' and may generate the current MySQL format byte format in the WHERE clause (typically if the client reserves a 14 byte buffer for TIMERSTAMPS etc). In SQL: UPDATE table SET column = 'something' WHERE time_column = '01:01:01': .. this update will fail if the currently stored value is '01:01:01:010001'; and the rigth query in the context would be. UPDATE table SET column = 'something' WHERE time_column = '01:01:01:010001'; Ideally I think there should be a configuration parameter and a global variable to SET time_accuracy = full_second|millisecond|microsecond. Did somebody have considerations about same? I definitely think that lots of applications using a TIME|TIMESTAMP|DATETIME column in the WHERE-clause of an UPDATE statement will need some rewrite to be upgradable to MariaDB 5.3 -- Peter

4 5

Re: [Maria-developers] [Commits] Rev 3020: MWL#192: Non-blocking client API for libmysqlclient. in http://bazaar.launchpad.net/~maria-captains/maria/5.2
by Kristian Nielsen 20 Sep '11

20 Sep '11

Hi Monty, Please find included the patch for MWL#192, non-blocking client API, for review. This patch is against MariaDB 5.2.8, though I expect the feature will eventually be merged and pushed to MariaDB 5.5. One thing in particular I would like to ask for advice on is if there are ways to improve the integration with libmysql/NET/Vio, as you know this code much better than me. - Kristian.

2 4

[Maria-developers] strange lines in test_if_skip_sort_order()
by Sergei Golubchik 14 Sep '11

14 Sep '11

Hi. At the end of test_if_skip_sort_order() you put (in 5.3): 17959 /* 17960 orig_cond is a part of pre_idx_push_cond, 17961 no need to restore it. 17962 */ 17963 orig_cond= 0; 17964 orig_cond_saved= false; 17965 if (orig_cond_saved && !changed_key) 17966 tab->set_cond(orig_cond); Besides incorrect indentation, you set orig_cond_saved to false, and in the next line writes an if() statement that can only work if orig_cond_saved is true. If orig_cond_saved=false is correct, then this if() can be completely removed. Or, may be, orig_cond_saved should not be set to false? Regards, Sergei

1 0

[Maria-developers] MariaDB 5.3.1-beta
by Daniel Bartholomew 10 Sep '11

10 Sep '11

All, The packages for MariaDB 5.3.1-beta were uploaded to the primary mirror yesterday and all of the mirrors (except one) have the files now, so I've gone ahead and activated the download page and the release notes and changelog pages. * http://kb.askmonty.org/en/mariadb-531-release-notes * http://kb.askmonty.org/en/mariadb-531-changelog * http://downloads.askmonty.org/mariadb/5.3.1/ I will be waiting until Monday to send out the announcement email so if there is anything that should be added to the release notes, please let me know as soon as possible. Thanks. -- Daniel Bartholomew MariaDB - http://mariadb.org Monty Program - http://montyprogram.com AskMonty Knowledgebase - http://kb.askmonty.org

1 0

Re: [Maria-developers] [Commits] Rev 3182: BUG#833600: Wrong result with view + outer join + uncorrelated subquery (non-semijoin) in file:///home/psergey/dev2/5.3-push14/
by Oleksandr Byelkin 09 Sep '11

09 Sep '11

Hi! 8 сент. 2011, в 22:24, Sergey Petrunya написал(а): > At file:///home/psergey/dev2/5.3-push14/ > > ------------------------------------------------------------ > revno: 3182 > revision-id: psergey(a)askmonty.org-20110908192447-h8rmi1gvivwh59eh > parent: psergey(a)askmonty.org-20110908173810-mcq7fj9d14ynyckq > committer: Sergey Petrunya <psergey(a)askmonty.org> > branch nick: 5.3-push14 > timestamp: Thu 2011-09-08 23:24:47 +0400 > message: > BUG#833600: Wrong result with view + outer join + uncorrelated subquery (non-semijoin) > - The bug was caused by outer join being incorrectly converted into inner because of > invalid return values of Item_direct_view_ref::not_null_tables(). > - Provided a correct Item_direct_view_ref::not_null_tables() function. The patch is OK [skip]

1 0

Re: [Maria-developers] [Question #169828]: MariaDB 5.3.0 7 crash in 4 minutes
by Kristian Nielsen 08 Sep '11

08 Sep '11

"Philip Stoev" <pstoev(a)askmonty.org> writes: > Bug https://bugs.launchpad.net/maria/+bug/824463, which is in state > "Fix Committed", is still present. I assume it is waiting for a > review. There may be others like it. I think we are using "Fix committed" and "Fix released" somewhat inconsistently. I see two different policies both being used: 1. "Fix committed" means the fix is pushed to a main tree. "Fix released" is set when an official release is made containing the fix. 2. "Fix committed" means a patch has been made but not pushed to main tree yet (eg. there is a commit mail or maybe pushed to a feature branch). "Fix released" means the fix is in a main tree. I prefer (2), since it simplifies the maintenance of bug states. When a fix is pushed to the main tree, the developer can mark the bug "fix released" with a comment noting in which release the bug will appear (just the next release number in the appropriate main tree, eg. "Fix will appear in 5.3.1"). With (1), we need an extra manual step where "someone" goes through bugs after release and figures out which should be set to "Fix released". I do not think this extra work gives any tangible benefits. So my suggestion is to adopt (2) as policy for MariaDB. However, the most important thing is that we adopt a consistent policy, whatever it is. - Kristian.

2 1