- developers - lists.mariadb.org

[Maria-developers] How handle_rpl_parallel_thread rollback partial transaction when STOP SLAVE In parallel replication
by nanyi607rao 26 Feb '14

26 Feb '14

hi Kristian, I have a quesion about parallel replication. In handle_rpl_parallel_thread(), a worker thread has got a whole transaction events, but it only apply partial events. this thread wouldl skip left events when do STOP SLAVE(is that rigth?) ,because sql_worker_killed() return true. but it seems that partial transaction won't be rollbacked for wait_for_prior_commit() always return false. do me wrong? or how would it rollback that partial transaction. 2014-02-25 nanyi607rao

2 3

[Maria-developers] GSOC 2014 participation
by Suyash Loiwal 26 Feb '14

26 Feb '14

Hello I am Suyash Loiwal from India, currently pursuing my B.Tech from Manipal institute of Technology, Manipal. I would like to take a project under your organization. Can someone please guide me how to start? Thanks Suyash

2 1

[Maria-developers] MDEV-4309: Review for 201402181003_sanja_copy_calls_patch.diff
by Sergey Petrunia 25 Feb '14

25 Feb '14

Hi Sanja, My input for 201402181003_sanja_copy_calls_patch.diff: * memcpy_field_possible() should have a function comment mentioning that it checks whether memcpy_field_value() can be used. * field_conv_incompatible() should have a function comment mentioning that it is a function that is used instead of field_conv() when we know in advance that memcpy_field_possible(...)==false. Ok to push after this is addressed. BR Sergei -- Sergei Petrunia, Software Developer MariaDB | Skype: sergefp | Blog: http://s.petrunia.net/blog

1 0

[Maria-developers] MariaDB 5.5.36 stable and MariaDB Galera 10.0.7 alpha release prep
by Daniel Bartholomew 25 Feb '14

25 Feb '14

All, I've completed most of the prep work for the MariaDB 5.5.36 (stable) and MariaDB Galera Cluster 10.0.7 (alpha) releases. Current plan is to activate and announce these releases together on Monday, 24 Feb before noon US Eastern Time (barring any last-minute issues). Draft changelogs and release notes are at the following locations: MariaDB 5.5.36 stable - https://mariadb.com/kb/en/mariadb-5536-release-notes/ - https://mariadb.com/kb/en/mariadb-5536-changelog/ MariaDB Galera Cluster 10.0.7 alpha - https://mariadb.com/kb/en/mariadb-galera-cluster-1007-release-notes/ - https://mariadb.com/kb/en/mariadb-galera-cluster-1007-changelog/ Please let me know ASAP of any additions, changes, typos, etc.... The 5.5.36 release notes in particular are very generic at the moment, so I'm very interested in additions to that page (please jump in and add!). The files for these releases are gradually making their way to MariaDB mirrors world wide. The primary mirror has them now if you want to get a jump on the competition: http://ftp.osuosl.org/pub/mariadb/mariadb-galera-10.0.7 http://ftp.osuosl.org/pub/mariadb/mariadb-5.5.36 Obilgatory note #1: The plan is for these files to be the officially released files without any changes, but that may change if something unexpected comes up (and such things have happened in the past). For those that would like to test the MariaDB Galera Cluster 10.0.7-alpha yum and apt repositories prior to the actual release, because that's just how you roll, the following config entries should get you going (you'll need to copy/paste/edit for whatever distro you are actually using/testing/playing-around-with): # - - Ubuntu - - - - - - - - - - - - - - - - # MariaDB 10.0.8 Ubuntu test mariadb.list w/MGC 10.0.7-alpha deb http://ftp.osuosl.org/pub/mariadb/mariadb-10.0.8/repo/ubuntu saucy main # - - Debian - - - - - - - - - - - - - - - - - # MariaDB 10.0.8 Debian test mariadb.list w/MGC 10.0.7-alpha deb http://ftp.osuosl.org/pub/mariadb/mariadb-10.0.8/repo/debian wheezy main # - - Red Hat - - - - - - - - - - - - - - - - # MariaDB 10.0.8 RedHat MariaDB-test.repo w/ MGC 10.0.7-alpha [mariadb] name = MariaDB baseurl = http://yum.mariadb.org/10.0.8-upd/rhel6-amd64 gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB gpgcheck=1 # - - Fedora - - - - - - - - - - - - - - - - - # MariaDB 10.0.8 Fedora MariaDB-test.repo w/ MGC 10.0.7-alpha [mariadb] name = MariaDB baseurl = http://yum.mariadb.org/10.0.8-upd/fedora20-amd64 gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB gpgcheck=1 Obligatory note #2: These test alpha repos, if you use them, should be switched to the official ones (as produced by the repository configuration generator) after the release is officially out. Obligatory disclaimer #1: These test alpha repos are _completely_ untested. They may not work at all. Obligatory disclaimer #2: MariaDB Galera Cluster 10.0.7 is an ALPHA release. You have been warned. You're on your own. Good luck and Godspeed. :) Thanks. -- Daniel Bartholomew MariaDB

4 4

[Maria-developers] MySQL Optimizer Trace Questions
by Christian Rober 25 Feb '14

25 Feb '14

Hello All, I work for TokuTek as a Storage Engine developer and I have been using the, relatively, new optimizer trace functionality. I have found the results very helpful when combined with analyzing the source code, but there a few questions I want to ask. Here is some output from the trace for a recent SELECT query on an InnoDB table: At the end of the trace, it shows the index chosen by, what I presume, is the optimizer: ... "considered_execution_plans": [ { "plan_prefix": [], "table": "`reports` `a`", "best_access_path": { "considered_access_paths": [ { "access_type": "ref", "index": "reports_group_id", "rows": 1.55e6, "cost": 411057, "chosen": true }, ... ] }, "cost_for_plan": 411057, "rows_for_plan": 1.55e6, "chosen": true } ] }, ... Here are the cost results for some rejected alternative indexes, (note: the row count for two of them is similar to the chosen index): ... "analyzing_range_alternatives": { "range_scan_alternatives" ... "rows": 2377102, "cost": 2.81e6, ... "rows": 1554164, "cost": 1.84e6, ... "rows": 2346664, "cost": 2.78e6, ... "rows": 1554164, "cost": 1.84e6, ... Here is the cost analysis for a table scan, from the beginning of the trace (still not as good as the above chosen index, but close on cost): ... "table": "`reports` `a`", "range_analysis": { "table_scan": { "rows": 3108329, "cost": 655076 }, ... Related to the fact that the table scan analysis is dominated by the large row count, and probably rejected as a valid plan compared to the chosen index for that very reason: 1. How is the row count more than merely informational to the optimizer? I had the impression the row count did not directly contribute to the optimizer's decision as much as the estimated cost, or that the row count was already accounted for/factored into in the final cost measurement. 2. Related to that question, what is cost exactly? Is there a unit of measurement (ex: Time, Disk Seeks, etc.)? 3. Is cost more important than row count or equally important? 4. What is the genesis of the cost variable displayed in the trace? I assume it is just a guess on the respective storage engine's part of how expensive (in terms of disk access, processing, time, etc.) getting the rows will be for the query. thanks in advance, Christian

2 1

[Maria-developers] We are participating in Google Summer of Code 2014
by Colin Charles 25 Feb '14

25 Feb '14

Hi, It is with great pleasure that I can inform you that we have been accepted as an organisation to participate in Google Summer of Code 2014! It would be great to see more ideas pop up here: https://mariadb.com/kb/en/google-summer-of-code-2014/ More mentors are always wanted! I presume we will see a lot more student discussions here as well. If you have any questions that aren't answered on the lists, please send me a personal note Here's to more features & contributors in 2014. cheers, -colin -- Colin Charles, Chief Evangelist MariaDB | t: +6-012-204-3201 | Skype: colincharles

1 0

[Maria-developers] MariaDB C-API and specific P_S tables
by Peter Laursen 24 Feb '14

24 Feb '14

THis is probably a question that Gerog Richter (or possibly Wlad) could reply to. I came across this bug report: http://bugs.mysql.com/bug.php?id=71801 .. files by former MySQL/Sun/Oracle supporter Veleriuy Kravtchuk We have a 64 bit C-application compiled with MariaDB C-API (on and for Windows 64 bit). I connect to MySQL 5.6.15 and execute SELECT * FROM `session_connect_attrs`; /* PROCESSLIST_ID ATTR_NAME ATTR_VALUE ORDINAL_POSITION -------------- --------------- ---------- ------------------ 2 _os Windows 0 2 _client_name libmariadb 1 2 _pid 5012 2 2 _thread 4640 3 2 _platform x86 4 2 _client_version 1.1.2 5 */ With the MySQL CLI 5.6.15, you will get /* PROCESSLIST_ID ATTR_NAME ATTR_VALUE ORDINAL_POSITION -------------- --------------- ---------- ------------------ 4 _os Win64 0 4 _client_name libmysql 1 4 _pid 4888 2 4 _thread 4320 3 4 _platform x86_64 4 4 program_name mysql 5 4 _client_version 5.6.15 6 */ The differences I notice are * Our application populates P_S with "Windows" - not "Win64" as the 5.6.15 CLI * Our application populates 'P_S with "x86" and not "x86_64". * Our application does not populate P_S with a "program_name". But it has a name of course! MySQL 5.6 docs at http://dev.mysql.com/doc/refman/5.6/en/performance-schema-connection-attrib… (as far as I can understand) that the client should use mysql_options() and mysql_options4() C API functions to populate P_S with all information. I have two questions: 1) Will the first 2 differences listed require a patch in our code or in libmariadb? 2) Obviosuly the lacking program name in the P_S tables is something that we will neeed to take care of ourselves. However I think that mysql_options4() was added in MySQL 5.6 and the MariaDB API does not supprot it currently (it is targeted to be compatible with Oracle 5.5 API, I think). And to populate the program name we may need to use mysql_options4(). Am I right?

2 4

[Maria-developers] Using MariaDB SQL for other storage engine
by Amith Nagarajappa 24 Feb '14

24 Feb '14

Hello, I am a database guy and want to plug mariaDB sql engine for other storage engine. If I want to plugin a storage engine with mariadb to use mariadb's SQL should i use handler interface in the storage/examples directory. I am not sure how to start with this interface implementation for MariaDB. Any help or docs or weblink on this would be helpful. Thanks and Regards, Amith

3 4

[Maria-developers] GROUP BY with non-grouped column returns NULL in some cases?
by Pavel Ivanov 24 Feb '14

24 Feb '14

Hi, I've noticed a difference in MariaDB's behavior compared to its documentation and compared to MySQL 5.1 (didn't check with MySQL 5.5 or 5.6 yet), and I wanted to know what's your opinion -- is it a bug or a conscious difference and documentation is just lagging. This doc https://mariadb.com/kb/en/select/#group-by says: "If you select a non-grouped column or a value computed from a non-grouped column, it is undefined which row the returned value is taken from". I believe this implies that selected value must be returned from a row group, not just something random. But I have a scenario when NULL is returned instead of real values. I understand that this is completely undefined behavior in SQL standard, but MySQL and MariaDB seem to have a documented support for this, that's why I'm asking. Here's the mysql session log: Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 5 Server version: 10.0.8-MariaDB-log Source distribution Copyright (c) 2000, 2013, Oracle, Monty Program Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MariaDB [(none)]> create database test; Query OK, 1 row affected (0.00 sec) MariaDB [(none)]> use test; Database changed MariaDB [test]> CREATE TABLE t (id bigint(20), name varchar(30), parent bigint(20), primary key (id)) ENGINE=InnoDB; Query OK, 0 rows affected (0.27 sec) MariaDB [test]> INSERT INTO t values (1, 'a', NULL), (4, 'b', 1), (5, 'c', 4), (10, 'd', 1); Query OK, 4 rows affected (0.04 sec) Records: 4 Duplicates: 0 Warnings: 0 MariaDB [test]> SELECT t1.id, t1.name, t2.id, t2.name FROM t t1 LEFT OUTER JOIN t t2 ON (t1.parent = t2.id and t2.name <> 'a') GROUP BY t1.id; +----+------+------+------+ | id | name | id | name | +----+------+------+------+ | 1 | a | NULL | NULL | | 4 | b | NULL | NULL | | 5 | c | NULL | NULL | | 10 | d | NULL | NULL | +----+------+------+------+ 4 rows in set (0.00 sec) MariaDB [test]> SELECT t1.id, t1.name, t2.id, t2.name FROM t t1 LEFT OUTER JOIN t t2 ON (t1.parent = t2.id and t2.name <> 'a'); +----+------+------+------+ | id | name | id | name | +----+------+------+------+ | 1 | a | NULL | NULL | | 4 | b | NULL | NULL | | 5 | c | 4 | b | | 10 | d | NULL | NULL | +----+------+------+------+ 4 rows in set (0.00 sec) MariaDB [test]> SELECT t1.id, t1.name, t2.id, t2.name FROM t t1 LEFT OUTER JOIN t t2 ON (t1.parent = t2.id and t2.name <> 'a') GROUP BY t1.id, t1.name; +----+------+------+------+ | id | name | id | name | +----+------+------+------+ | 1 | a | NULL | NULL | | 4 | b | NULL | NULL | | 5 | c | 4 | b | | 10 | d | NULL | NULL | +----+------+------+------+ 4 rows in set (0.00 sec) MariaDB [test]> SELECT t1.id, t1.name, t2.id, t2.name FROM t t1 LEFT OUTER JOIN t t2 ON (t1.parent = t2.id) GROUP BY t1.id; +----+------+------+------+ | id | name | id | name | +----+------+------+------+ | 1 | a | NULL | NULL | | 4 | b | 1 | a | | 5 | c | 4 | b | | 10 | d | 1 | a | +----+------+------+------+ 4 rows in set (0.00 sec) As you see the first query returns NULLs instead of real values which can be seen in second query without GROUP BY. And if I add another column to GROUP BY or remove one condition from JOIN I can see real values again. I've also tested with the table without PRIMARY KEY and it also returned real values in the first query. So is this a bug? Thank you, Pavel

2 2

[Maria-developers] Interested in GSOC
by Gopichand Paturi 24 Feb '14

24 Feb '14

Dear Sir/Madam, I am a student of Computer Science at BITS PILANI, India. I am interested in working as a developer for MariaDB in 2014. Can someone please let me know the ideas and proposed projects this year? Someone please guide me what to familiarize myself to be helpful and contribute for MariaDB. I am C++ developer....with good knowledge in Data Structures,Algorithms,Database Systems. Thanks& Regards, Gopichand.

2 1