- developers - lists.mariadb.org

[Maria-developers] MWL#36 documentation
by Kristian Nielsen 12 Jan '11

12 Jan '11

Hi Daniel, While merging Percona patches, I noticed a couple of issues with our documentation relating to MWL#36, I was hoping you could handle them: - The MWL#36 is mentioned in the changelog/release notes: http://kb.askmonty.org/v/mariadb-520-release-notes However it seems to be missing from "mariadb-vs-mysql": http://kb.askmonty.org/v/mariadb-versus-mysql-features - There is some documentation of the MWL#36 in the form of a table entry for --rewrite-db here: http://kb.askmonty.org/v/mysqlbinlog However, that page mentions the feature introduced in MariaDB 5.2.1, while the release notes say 5.2.0. I wonder which is correct? - Kristian.

1 0

[Maria-developers] Multiple default values for timestamps
by Dolf Schimmel 09 Jan '11

09 Jan '11

Hey folks, On IRC I read somewhere that multiple timestamps cant have multiple default values using NOW() (error ER_TOO_MUCH_AUTO_TIMESTAMP_COLS). I tried to find out why this limitation is in place, but was not able to do so. The only thing I (or rather someone in #mysql and #maria) was able to find was this, in sql/field.cc (line 4729): > Actually SQL-99 says that we should allow niladic functions (like NOW()) > as defaults for any field. Current limitations (only NOW() and only > for one TIMESTAMP field) are because of restricted binary .frm format > and should go away in the future. I removed the check that spits out this error and updated the tests. Now I'll admit I'm not sure how to properly test this, but so far the entire testsuite passes. It may be that I'm missing any reasons for this limitation, or that tests may be missing/inaccurate. If you have any opinions on this, please let me know. You can find it in: lp:~freeaqingme/maria/improv-allowMultipleCurTimestampInDefaultOnTable Regards, Dolf Schimmel -- Freeaqingme p.s. Sorry for the long branchname, couldn't think of something shorter that was still descriptive :D

2 3

[Maria-developers] WL#173 New (by Sergei): temporal types with sub-second resolution
by worklog-noreply＠askmonty.org 09 Jan '11

09 Jan '11

----------------------------------------------------------------------- WORKLOG TASK -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- TASK...........: temporal types with sub-second resolution CREATION DATE..: Sun, 09 Jan 2011, 20:08 SUPERVISOR.....: Sergei IMPLEMENTOR....: Sergei COPIES TO......: Monty CATEGORY.......: Server-Sprint TASK ID........: 173 (https://askmonty.org/worklog/?tid=173) VERSION........: Server-5.3 STATUS.........: Assigned PRIORITY.......: 80 WORKED HOURS...: 0 ESTIMATE.......: 80 (hours remain) ORIG. ESTIMATE.: 80 PROGRESS NOTES: DESCRIPTION: We will add a support for timestamps (and other temporal types) with a sub-second resolution. Syntax ^^^^^^ The syntax for declaring a column is the conventional TIMESTAMP(X) DATETIME(X) TIME(X) where X is the scale - that is, number of digits after the decimal dot. TIMESTAMP(0) is the same as the current TIMESTAMP. The existing syntax (without specifying the scale) will, of course, work as before. X=6 means microseconds, X=9 means nanoseconds, X=12 means picoseconds. The max supported value of X is [undecided], but will be no less than 6. Possibly, we will do 6 in this WL - because it keeps syntax and protocol changes to the minimum, microseconds are already supported there. If needed, we will increase the timestamp precision later - the implementation (see below) needs to keep it in mind. The time and datetime literals can be written with the fractional part, for example '2011-01-08 20:29:26.1234567890'. This is alrteady supported. Client-server protocol ^^^^^^^^^^^^^^^^^^^^^^ We will not change the binary client-server protocol. It only supports microseconds in the MYSQL_TIME::second_part - we will truncate longer timestamps to this precision. Show commands and I_S ^^^^^^^^^^^^^^^^^^^^^ SHOW COLUMNS and SHOW CREATE TABLE will show TIMESTAMP(X) as appropriate (similar to INT(N) and DECIMAL(M,N) types). I_S.COLUMNS will *not* show '(X)' in the DATA_TYPE column, but it *will* show it in the COLUMN_TYPE column. It will show X in the new DATETIME_PRECISION column. Functions ^^^^^^^^^ The following functions need to be fixed to support sub-seconds: CAST() - as DATETIME(X), etc CONVERT_TZ() SEC_TO_TIME() TIME_TO_SEC() MAKETIME() - perhaps? FROM_UNIXTIME() - probably not UNIX_TIMESTAMP() - probably not UTC_TIMESTAMP(), UTC_TIME(), NOW(), CURTIME() and synonyms - probably not, high-precision NOW() is a separate task P.S. See also http://forge.mysql.com/worklog/task.php?id=946 ESTIMATED WORK TIME ESTIMATED COMPLETION DATE ----------------------------------------------------------------------- WorkLog (v4.0.0)

1 0

[Maria-developers] The query cache patch fixed by me and then Monty (most changes by him)
by Oleksandr Byelkin 07 Jan '11

07 Jan '11

Hi! Here is changes which was done: - Fixed switching off of the query cache -- memory freed now -- after completely switching of it could be switched on again - Cleaned up saving the query without comments and space - Added all the missing test cases (and checked results) - Added more symbols to LEX to make parsing faster (not part of this thing, but I thought it was better to get this done now as I was looking at the code) - Fixed all the issues that I had in my review of query parsing - Cleaned up mysql-tests -- Made test results easier to read -- removed 'percona' prefix from tests names -- Made test result files notable smaller - Added 'thd' to query_cache::invalidate calls, to remove some current_thd usages - Added variable thd->query_cache_is_valid, that is set to 1 if query_cache could possible read query from the query_cache -- If not, there is no reason to put the query in the cache The above change allowed me to remove safe_to_cache_queries from send_result_to_client() and make this part of the code not depending in lex_start() - simplified a couple of functions to use pointers instead of index - Fixed bug where SQL_NO_CACHE was not detected if followed by tab, newline or return i> that's about it 2 Vadim & Oleg: If you OK with changes above and the patch then it will be included in our tree.

2 3

[Maria-developers] [patch] A few typos
by Dolf Schimmel 07 Jan '11

07 Jan '11

Morning folks, I was looking at the source for a certain function in MariaDB (see the patch and you'll know which one :D ). While grepping I found a couple of typos and since I don't have commit rights, and couldn't find where to send the patch, I decided to send it here :) The diff is made against trunk, but I guess it should be fairly easy to patch against other branches as well. Kind regards, Dolf Schimmel -- Freeaqingme

2 1

Re: [Maria-developers] Restarting cooperation of Percona and Monty Programming AB
by Kristian Nielsen 06 Jan '11

06 Jan '11

Michael Widenius <monty(a)askmonty.org> writes: >>>>>> "Kristian" == Kristian Nielsen <knielsen(a)knielsen-hq.org> writes: > > <cut> > > Kristian> Anyway, I fixed the patch, added test cases, and merged into MariaDB. It is > Kristian> pushed here: > > Kristian> lp:~knielsen/maria/5.2-percona-row_based_replication_without_primary_key > > Kristian> Here is the commit message: > > Kristian> Merge Percona patch row_based_replication_without_primary_key.patch into MariaDB. > > Kristian> This patch improves the selection of index to use to apply row-based > Kristian> DELETE and UPDATE events on tables with no primary key (original code > Kristian> picks the first index unconditionally). > Kristian> If ANALYZE TABLE is done, the index cardinalities will be compared and > Kristian> the best index will be used. > > Kristian> Fixes some problems in the original patch: > > Kristian> - Without ANALYZE TABLE, rec_per_key statistics is not available; in this > Kristian> case the original patch could choose a really bad index, even ignoring > Kristian> a primary key. > > Kristian> - The original patch did not consider multi-column keys correctly, and > Kristian> could thus pick a less desirable single-column key over a good > Kristian> multi-column index. > > Kristian> Also fixes Bug#58997, and adds test cases. > > Kristian> Monty, how do I include it in our percona tree?, can I just push here: > > Kristian> lp:~maria-captains/maria/5.2-percona > > Yes, feel free to push if no one from Percona has any problems with > your patch. So, any objections or comments from Percona on this patch? I've included the patch below for convenience. - Kristian.

2 2

[Maria-developers] WL#172 New (by Monty): Add support for prepared statements to HANDLER READ
by worklog-noreply＠askmonty.org 03 Jan '11

03 Jan '11

----------------------------------------------------------------------- WORKLOG TASK -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- TASK...........: Add support for prepared statements to HANDLER READ CREATION DATE..: Mon, 03 Jan 2011, 19:19 SUPERVISOR.....: IMPLEMENTOR....: COPIES TO......: CATEGORY.......: Server-RawIdeaBin TASK ID........: 172 (http://askmonty.org/worklog/?tid=172) VERSION........: WorkLog-4.0 STATUS.........: Un-Assigned PRIORITY.......: 60 WORKED HOURS...: 0 ESTIMATE.......: 40 (hours remain) ORIG. ESTIMATE.: 40 PROGRESS NOTES: DESCRIPTION: Add support for prepared statements to HANDLER READ. As part of this work, move some of the word done during handler_read to handler_open to speed up HANDLER READ calls. Example: handler t1 open; prepare stmt from 'handler t1 read a=(?) limit ?,?'; set @a=16,@b=1,@c=100; execute stmt using @a,@b,@c; deallocate prepare stmt; ESTIMATED WORK TIME ESTIMATED COMPLETION DATE ----------------------------------------------------------------------- WorkLog (v4.0.0)

1 0

Re: [Maria-developers] [Commits] Rev 2999: Speed up `mtr --parallel=<lots>` by scheduling some slow tests earlier. in http://bazaar.launchpad.net/~maria-captains/maria/5.1
by Sergei Golubchik 03 Jan '11

03 Jan '11

Hi, knielsen! On Jan 03, knielsen(a)knielsen-hq.org wrote: > At http://bazaar.launchpad.net/~maria-captains/maria/5.1 Hm. Why do you prefer to add a dummy include file to every "long" test, instead of using a separate file, like disabled.def ? I think it'd be easier to maintain in a separate file, and easier to extend later on. Regards, Sergei

2 2

[Maria-developers] Logoff trigger for MariaDB
by Oli Sennhauser 31 Dec '10

31 Dec '10

Hi all, As suggested by Sergei we should discuss this here. Copying the login trigger stuff to a place in the code where I thought it makes sense I have created a logout trigger. This gives the capability to track a session from its beginning to its end and collects all the data from each session. With this capability we can start thinking about auditing of MySQL users like it is needed/wanted from big companies. I am NOT a developer and I was just lucky that it worked out how I did it. So I am not of much help for an other approach as Sergei hinted in his comment. Now: free to discuss... http://www.fromdual.com/mysql-logon-and-logoff-trigger-for-auditing Regards, Oli -- FromDual - Vendor independent and neutral MySQL consulting. Website http://www.fromdual.com/ Skype fromdual Jabber fromdual(a)swissjabber.ch Yahoo IM fromdual Xing https://www.xing.com/profile/Oliver_Sennhauser LinkedIn http://ch.linkedin.com/in/shinguz Twitter http://twitter.com/shinguz

2 2

Re: [Maria-developers] [Fwd: [Commits] Rev 2998: Fixed LP bug #639935 (bug #58727). in file:///home/igor/maria/maria-5.1-bug693935/]
by Oleksandr Byelkin 24 Dec '10

24 Dec '10

Hi! 24 Dec 2010, в 06:45, Igor Babaev написал(а): > Sanja, > > Please review this fix ASAP. > We need it to move on with 5.3 The patch is OK, but I would prefer to have comment before Item::quick_fix_field() that this method is only for optimizer needs, it can be used only for certain Items controlled by optimizer and maybe add that only Item_func_* need recursion for this. But you could write comments much better then I so it is up to you how write the comment. > > Regards. > Igor. > > -------- Original Message -------- > Subject: [Commits] Rev 2998: Fixed LP bug #639935 (bug #58727). in > file:///home/igor/maria/maria-5.1-bug693935/ > Date: Fri, 24 Dec 2010 06:42:05 +0200 (EET) > From: <igor(a)askmonty.org> > Reply-To: maria-developers(a)lists.launchpad.net > To: <commits(a)mariadb.org> > > At file:///home/igor/maria/maria-5.1-bug693935/ > > ------------------------------------------------------------ > revno: 2998 > revision-id: igor(a)askmonty.org-20101224044150-p9yja1e87riwjh7g > parent: monty(a)askmonty.org-20101221172350-wqtf0t6evpc0un4b > committer: Igor Babaev <igor(a)askmonty.org> > branch nick: maria-5.1-bug693935 > timestamp: Thu 2010-12-23 20:41:50 -0800 > message: > Fixed LP bug #639935 (bug #58727). > When the optimizer creates items out of other items it does > not have to call the fix_fields method. Usually in these > cases it calls quick_fix_field() that just marks the > created item as fixed. If the created item is an Item_func > object then calling quick_fix_field() works fine if the > arguments of the created functional item are already fixed. > Otherwise some unfixed nodes remain in the item tree and > it triggers an assertion failure whenever the item is > evaluated. > > Fixed the problem by making the method quick_fix_field > virtual and providing an implementation for the class > Item_func objects that recursively calls the method > for unfixed arguments of any functional item. [skip]

1 0