- developers - lists.mariadb.org

Re: [Maria-developers] MariaDB Galera replication
by Pavel Ivanov 18 Nov '13

18 Nov '13

I'm starting a new thread as this is already doesn't have anything to do with the original topic. On Fri, Nov 15, 2013 at 10:46 AM, Alex Yurchenko <alexey.yurchenko(a)codership.com> wrote: >>> Please pardon this arrogant interruption of your discussion and shameless >>> self-promotion, but I just could not help noticing that Galera >>> replication >>> was designed specifically with these goals in mind. And it does seem to >>> achieve them better than semi-sync plugin. Have you considered Galera? >>> What >>> makes you prefer semi-sync over Galera, if I may ask? >> >> >> To be honest I never looked at how Galera works before. I've looked at >> it now and I don't see how it can fit with us. The major disadvantages >> I immediately see: >> 1. Synchronous replication. That means client must wait while >> transaction is applied on all nodes which is unacceptably big latency >> of each transaction. And what if there's a network blip and some node >> becomes inaccessible? All writes will just freeze? I see the statement >> that "failed nodes automatically excluded from the cluster", but to do >> that cluster must wait for some timeout in case it's indeed a network >> blip and node will "quickly" reconnect. And every client must wait for >> cluster to decide what happened with that one node. >> 2. Let's say node fell out of the cluster for 5 minutes and then >> reconnected. I guess it will be treated as "new node", it will >> generate state transfer and the node will start downloading the whole >> database? And while it's trying to download say 500GB of data files >> all other nodes (or maybe just donor?) won't be able to change those >> files locally and thus will blow up its memory consumption. That means >> they could quickly run out of memory and "new node" won't be able to >> finish its "initialization"... >> 3. It looks like there's strong asymmetry in starting cluster nodes -- >> the first one should be started with empty wsrep_cluster_address and >> all others should be started with the address of the first node. So I >> can't start all nodes uniformly and then issue some commands to >> connect them to each other. That's bad. >> 4. What's the transition path? How do I upgrade MySQL/MariaDB >> replicating using usual replication to Galera? It looks like there's >> no such path and the solution is stop the world using regular >> replication and restart it using Galera. Sorry I can't do that with >> our production systems. >> >> I believe these problems are severe enough for us, so that we can't >> work with Galera. > > > Pavel, you seem to be terribly mistaken on almost all accounts: > > 1. *Replication* (i.e. data buffer copying) is indeed synchronous. But > nobody said that commit is. What Galera does is very similar to semi-sync, > except that it does it technically better. I would not dare to suggest > Galera replication if I didn't believe it to be superior to semi-sync in > every respect. Well, apparently we have a different understanding of what the term "synchronous replication" means. This term is all over the Galera doc, but I didn't find the detailed description of how actually Galera replication work. So I assumed that my understanding of the term (which actually seem to be in line with wiki's definitions http://en.wikipedia.org/wiki/Replication_(computing) ) is what was implied there. So I hope you'll be able to describe in detail how Galera replication works. > As an example here's an independent comparison of Galera vs. > semi-sync performance: > http://linsenraum.de/erkules/2011/06/momentum-galera.html. This is a nice blog post written in German and posted in 2011. And while Google Translate gave me an idea what post was about it would be nice to see something more recent and with better description of what was the actual testing set up. > In fact, majority > of Galera users migrated from the regular *asynchronous* MySQL replication, > which I think is a testimony to Galera performance. I don't mean to troll, but this can also mean that everyone who migrated didn't care much about performance and Galera's performance was within sane boundaries... BTW, just found here https://mariadb.com/kb/en/mariadb-galera-cluster-known-limitations/ : "by design performance of the cluster cannot be higher than performance of the slowest node; however, even if you have only one node, its performance can be considerably lower comparing to running the same server in a standalone mode". That contradicts your words. > 2. Node reconnecting to cluster will normally receive only events that it > missed while being disconnected. This seem to contradict to the docs. Again from https://mariadb.com/kb/en/mariadb-galera-cluster-known-limitations/ : "After a temporary split, if the 'good' part of the cluster was still reachable and its state was modified, resynchronization occurs". > 3. You are partially right about it, but isn't it much different from > regular MySQL replication where you first need to set up master and then > connect slaves (even if you have physically launched the servers at the same > time). Operation of setting up master and then connecting slaves consists of mostly only executing CHANGE MASTER TO and then START SLAVE on all slaves after all MySQL instances (including master) were started with the same set of command line flags. This is fundamentally different from starting instances with different arguments, especially when these arguments should be different depending on whether the replica is starting first or there's already some other replica running. > Yet, Galera nodes can be started simultaneously and then joined > together by setting wsrep_cluster_address from mysql client connection. This > is not advertised method, because in that case state snapshot transfer can > be done only by mysqldump. If you set the address in advance, rsync or > xtrabackup can be used to provision the fresh node. This is of course better because I can start all instances with the same command line arguments. But transferring snapshot of a very big database using mysqldump, and causing the node that creates mysqldump to blow up memory consumption during the process, that is still a big problem. > 4. Every Galera node can perfectly work as either master or slave to native > MySQL replication. So migration path is quite clear. Nope, not clear yet. So I'll be able to upgrade all my MySQL instances to a Galera-supporting binary while they are replicating using standard MySQL replication. That's good. Now, how the Galera replication is turned on after that? What will happen if I just set wsrep_cluster_address address on all replicas? What will replicas do, and what will happen with the standard MySQL replication? > It is very sad that you happen to have such gross misconceptions about > Galera. If those were true, how would MariaDB Galera Cluster get paying > customers? Care to share some numbers? Like what's the rough amount of those paying customers? What size is the biggest installation -- number of clusters, replicas, highest QPS load? I'm not asking to share any confidential information, but the rough ballpark of the numbers would be helpful. > May be my reply will convince you to have a second look at it. > (In addition to the above Galera is fully multi-master, does parallel > applying and works great in WAN) I hope your explanation of how Galera replication work will help me understand how great it works over WAN and how you could make full multi-master work without fully synchronous replication in my understanding of that term. Pavel

3 9

[Maria-developers] What is bundled libevent library for?
by Pavel Ivanov 18 Nov '13

18 Nov '13

Sergei, Do you know why MariaDB sources have libevent library bundled with them? I don't see it being used anywhere. I see it was added in this commit by Monty http://bazaar.launchpad.net/~maria-captains/maria/10.0/revision/3492.3.1, but even in that commit I can't find any usages of the library. So should it be removed from MariaDB? Thank you, Pavel

4 4

[Maria-developers] Why local modifications to PCRE library?
by Pavel Ivanov 17 Nov '13

17 Nov '13

Alexander, I see you've included the full source of PCRE library into MariaDB tree and even made some local modifications which are not included into PCRE upstream. Could you please explain why did you do that? Why not allow to build with system standard PCRE library? I understand that you could have needed some modifications and thus could want to include sources from PCRE trunk to allow users to build with modifications when their system-wide library is too old. But as I don't see your modifications on PCRE trunk that means you probably had something different in mind, and decided to incur the pain of constantly updating the included sources and merging security fixes. So why did you decide to do that? Thank you, Pavel

3 7

Re: [Maria-developers] Semisync plugin incompatibility
by Kristian Nielsen 16 Nov '13

16 Nov '13

Pavel Ivanov <pivanof(a)google.com> writes: > We've noticed recently that semisync_master plugin in MariaDB (which > apparently was fully inherited from MySQL) is seriously incompatible > with our understanding of the purpose of semi-sync replication. This > incompatibility was apparently introduced as a fix for > http://bugs.mysql.com/bug.php?id=45672. The "major no-no" that bug So as I understand it, this bug is about what should happen when semisync is enabled, but no slaves are connected. Apparently before the fix of Bug#45672, an error was thrown late during COMMIT. So the transaction was committed (locally on the master), but the client still got an error back. And if I understand correctly, after the fix of Bug#45672, no error is thrown in the case where no slave is connected. > talks about is in our opinion the whole purpose of semi-sync > replication -- if transaction is not replicated to at least one slave > client shouldn't get OK even if transaction is committed locally on > the master. Also master shouldn't just turn off semi-sync replication > whenever it wants. So with "just turn off semi-sync replication whenever it wants" - what are you refering to here? I seem to remember that semisync has a timeout, and it gets disabled if that timeout triggers? My guess is that this is what you have in mind, but I wanted to ask to make sure ... > We will fix this problem for us, but first I wanted to understand > what's your view of the purpose of semi-sync replication and how you > think it should work? I need to know your opinion to understand how I > should fix this issue... Well, personally, I never was much interested in semi-sync. But it is my understanding that there is some interest, so I will answer with what small opinion I have. I suppose the general idea is that when client sees its COMMIT complete, it can know that its transaction exists in at least two places (master binlog + at least one slave relay log). So there is no longer any single point of failure that can cause loss of the transaction. Another point of view I is that semi-sync provides some sort of throttle on how fast the master can generate events compared to how fast the slaves can receive them: http://www.mysqlperformanceblog.com/2012/01/19/how-does-semisynchronous-mys… There was also a suggestion (and a patch is floating around somewhere) for "enhanced semisync replication": https://mariadb.atlassian.net/browse/MDEV-162 This delays not only client acknowledge but also InnoDB commit until the ack from at least one slave, which means that transactions are not visible to other clients until they exist on at least one slave in addition to on the master. Since this is _semi_-sync, not real two-phase commit synchronous replication, the main problem is that there is way to ensure consistency in the general error case. The transaction is already fully committed on the master, it cannot be rolled back. So we are left with the choice of one of two evils: 1. Report an error to the client. Most clients would then probably wrongly assume that the transaction was _not_ committed. There also does not seem to be much the client can do about the error except perhaps log an incident to the monitoring system. On the other hand, then at least the problem is not silently ignored. 2. Report success to the client but complain loudly in the error log (I assume this is what happens in current code). This leaves the client unaware that there is a problem (but presumably the monitoring system will catch the message in the error log). >From this summary, I think I can see the logic of the current behaviour: - It preserves protection against single-point-of-failure. If all slaves are gone, then we already have one failure, and unless we experience a double failure (master also failing before slave recovers), the transaction will eventually be sent to a slave and no overall failure happens. - If the client can anyway not do anything about the problem except notify the monitoring system, the server may as well do the notification itself. But the opposite point of view also has merit. The client asked for semi-sync behavior, but did not get it, and it does not even have a way to know about the problem. That is not good. Does the client currently at least get a warning for the COMMIT? I think it should (eg. the fix for Bug#45672 should at least have been to turn the error into a warning, not remove the error completely). What I think could make sense is if the client got an error during the prepare phase if no slaves are connected. In this case we _can_ roll back the transaction and give an error to the client without any issue of consistency. But it still leaves a small window where the last slave can disappear between the prepare and the commit phase and leave us with the original problem. I hope this helps you ... Maybe you can describe your use-case, and how you need things to work for that case? Personally I have nothing against changing this behaviour to something more logical, I am just not sure what the most logical behaviour is ... - Kristian.

4 8

[Maria-developers] parallel replication monitoring
by Giuseppe Maxia 15 Nov '13

15 Nov '13

What can I use to see the status of parallel replication? I am looking for: * how many workers are used; * in which schema they are working; * what query they are running. So far, I only see mysql.gtid_slave_pos and information_schema.processlist. Anything else available? Thanks in advance Giuseppe

4 6

[Maria-developers] Slave can take a very long time to start replication
by Pavel Ivanov 15 Nov '13

15 Nov '13

Kristian, As I understand currently when slave connects to master and wants to start replicating it passes GTID to start from, master finds binlog file where the earliest GTID is located and then scans through that file to find the exact binlog position to start sending binlog events from. If this binlog file is pretty big then scanning can take a very long time. I guess especially long when several slaves try to start replicating roughly at the same time. We observed 60-90 seconds between initial connection by the slave and the first real binlog events starting to flow. In this period of time slave doesn't receive anything from master and thus it's very easy to confuse such situation with connection loss, hit slave_net_timeout, reopen connection to the master again and force it to start searching through binlog file from the very beginning... Putting aside the argument of what value is good enough for slave_net_timeout, I'd say in any case slave taking 60 seconds to just start receiving binlog events from master is unacceptable. Did you think about this problem before? Maybe you've even planned already to implement some solution for this? Thank you, Pavel

2 1

[Maria-developers] Review for maria/10.0-serg/revision/3899 (MDEV-5248 Serious incompatibility and data corruption of DATETIME and DATE types due to get_innobase_type_from_mysql_type refactor combined with InnoDB Online DDL)
by Jeremy Cole 15 Nov '13

15 Nov '13

Serg, Thanks for looking into this. General comments: - The approach overall looks sound. I am very much in favor of reverting back to Oracle MySQL's type codes as you have, by reverting the refactor of get_innobase_type_from_mysql_type as you did. - You've mixed tabs and spaces in a bunch of places. InnoDB code should use tabs to indent. - It would probably be worth visually comparing to MySQL 5.6's get_innobase_type_from_mysql_type to ensure there is nothing new there aside from my comments. - It is almost certainly worth creating test cases with data files from older MariaDB and newer MySQL versions to exercise the usage of the code paths that only occur during upgrade; that doesn't need to happen here necessarily. Comments on the diff inline below. Regards, Jeremy (I removed the .result file differences as any issues there will be resolved by fixes to the .test.) === renamed file 'mysql-test/suite/innodb/t/1byte_data_int.opt' => > 'mysql-test/suite/innodb/t/data_types.opt' > === renamed file 'mysql-test/suite/innodb/t/1byte_data_int.test' => > 'mysql-test/suite/innodb/t/data_types.test' > --- mysql-test/suite/innodb/t/1byte_data_int.test 2013-10-31 22:20:05 > +0000 > +++ mysql-test/suite/innodb/t/data_types.test 2013-11-11 20:54:09 +0000 > @@ -1,25 +1,76 @@ > --source include/have_innodb.inc > > I would strongly suggest a detailed explanatory comment and warning added with "--echo #" so that it appears in the result file as well, explaining the repercussions changing any of the results here. > ---echo # Create a table with a 1-byte ENUM, 1-byte SET, and TINYINT > UNSIGNED. > - > CREATE TABLE t1 > ( > - t1_enum ENUM("a", "b", "c"), > - t1_set SET("a", "b", "c"), > - t1_tinyint_s TINYINT, > - t1_tinyint_u TINYINT UNSIGNED > + t1_BIGINT BIGINT, > + t1_BIGINT_UNSIGNED BIGINT UNSIGNED, > + t1_BINARY_100 BINARY(100), > + t1_BIT_2 BIT(2), > + t1_BIT_20 BIT(20), > + t1_BLOB BLOB, > + t1_CHAR_100 CHAR(100), > + t1_CHAR_100_BINARY CHAR(100) BINARY, > + t1_DATE DATE, > + t1_DATETIME DATETIME, > + t1_DATETIME_6 DATETIME(6), > + t1_DECIMAL_10_3 DECIMAL(10,3), > + t1_DECIMAL_10_3_UNSIGNED DECIMAL(10,3) UNSIGNED, > + t1_DOUBLE DOUBLE, > + t1_DOUBLE_UNSIGNED DOUBLE UNSIGNED, > + t1_ENUM ENUM("a", "b", "c"), > + t1_ENUM_BINARY ENUM('a','b') BINARY, > Why the mix of quote styles? For completeness this should also use an ENUM with > 254 elements to create a 2-byte ENUM. > + t1_FLOAT FLOAT, > + t1_FLOAT_UNSIGNED FLOAT UNSIGNED, > + t1_INT INT, > + t1_INT_UNSIGNED INT UNSIGNED, > + t1_LONGBLOB LONGBLOB, > + t1_LONGTEXT LONGTEXT, > + t1_MEDIUMBLOB MEDIUMBLOB, > + t1_MEDIUMINT MEDIUMINT, > + t1_MEDIUMINT_UNSIGNED MEDIUMINT UNSIGNED, > + t1_MEDIUMTEXT MEDIUMTEXT, > + t1_SET SET("a", "b", "c"), > + t1_SET_BINARY SET('a','b') BINARY, > Same mix of quote styles. Also should create a SET with > 8 elements to create a 2-byte SET. > + t1_SMALLINT SMALLINT, > + t1_SMALLINT_UNSIGNED SMALLINT UNSIGNED, > + t1_TEXT TEXT, > + t1_TIME TIME, > + t1_TIMESTAMP TIMESTAMP, > + t1_TIMESTAMP_5 TIMESTAMP(5), > + t1_TIME_4 TIME(4), > Maybe move up to TIME above (I guess these are all alphabetically sorted, but it may be better to sort only by the type [or add e.g. _0 to the base one]). Why 4 and not 3 or 6 or some other value? > + t1_TINYBLOB TINYBLOB, > + t1_TINYINT TINYINT, > + t1_TINYINT_UNSIGNED TINYINT UNSIGNED, > + t1_TINYTEXT TINYTEXT, > + t1_VARBINARY_100 VARBINARY(100), > + t1_VARCHAR_10 VARCHAR(10), > + t1_VARCHAR_10_BINARY VARCHAR(10) BINARY, > + t1_VARCHAR_500 VARCHAR(500), > + t1_VARCHAR_500_BINARY VARCHAR(500) BINARY, > + t1_YEAR_2 YEAR(2), > + t1_YEAR_4 YEAR(4) > ) ENGINE=InnoDB; > > ---echo # All t1 fields' mtypes should be 6 (DATA_INT). > - > SELECT > - name, > - mtype, > - (prtype & 512) = 512 AS is_unsigned > + name, CASE mtype WHEN 1 THEN "DATA_VARCHAR" > Put CASE on its own line (distinct from "name") and move the first WHEN to its own line. Re-indent other WHEN's to match. > + WHEN 2 THEN "DATA_CHAR" > + WHEN 3 THEN "DATA_FIXBINARY" > + WHEN 4 THEN "DATA_BINARY" > + WHEN 5 THEN "DATA_BLOB" > + WHEN 6 THEN "DATA_INT" > + WHEN 7 THEN "DATA_SYS_CHILD" > + WHEN 8 THEN "DATA_SYS" > + WHEN 9 THEN "DATA_FLOAT" > + WHEN 10 THEN "DATA_DOUBLE" > + WHEN 11 THEN "DATA_DECIMAL" > + WHEN 12 THEN "DATA_VARMYSQL" > + WHEN 13 THEN "DATA_MYSQL" > + WHEN 63 THEN "DATA_MTYPE_MAX" > + ELSE mtype > + END, > Add an alias e.g. AS base_type so that the result's column name isn't a truncated version of this CASE. > + IF((prtype & 512) = 512,"UNSIGNED","") AS is_unsigned > It's a bit weird to have is_unsigned be "UNSIGNED" or empty. Maybe YES/NO instead? Not a big deal I suppose. > FROM information_schema.INNODB_SYS_COLUMNS > WHERE name LIKE "t1\_%" > ORDER BY name; > > ---echo # Cleanup > - > DROP TABLE t1; > === modified file 'storage/innobase/dict/dict0stats.cc' > --- storage/innobase/dict/dict0stats.cc 2013-06-22 15:47:12 +0000 > +++ storage/innobase/dict/dict0stats.cc 2013-11-11 20:54:09 +0000 > @@ -176,7 +176,7 @@ > DATA_NOT_NULL, 192}, > > {"last_update", DATA_INT, > - DATA_NOT_NULL | DATA_UNSIGNED, 4}, > + DATA_NOT_NULL, 4}, > > {"n_rows", DATA_INT, > DATA_NOT_NULL | DATA_UNSIGNED, 8}, > @@ -207,7 +207,7 @@ > DATA_NOT_NULL, 192}, > > {"last_update", DATA_INT, > - DATA_NOT_NULL | DATA_UNSIGNED, 4}, > + DATA_NOT_NULL, 4}, > > {"stat_name", DATA_VARMYSQL, > DATA_NOT_NULL, 64*3}, > === modified file 'storage/innobase/handler/ha_innodb.cc' > --- storage/innobase/handler/ha_innodb.cc 2013-11-03 23:45:27 +0000 > +++ storage/innobase/handler/ha_innodb.cc 2013-11-11 20:54:09 +0000 > @@ -5745,67 +5745,94 @@ > 8 bits: this is used in ibuf and also when DATA_NOT_NULL is ORed to > the type */ > > - compile_time_assert((ulint)MYSQL_TYPE_STRING < 256); > - compile_time_assert((ulint)MYSQL_TYPE_VAR_STRING < 256); > - compile_time_assert((ulint)MYSQL_TYPE_DOUBLE < 256); > - compile_time_assert((ulint)MYSQL_TYPE_FLOAT < 256); > - compile_time_assert((ulint)MYSQL_TYPE_DECIMAL < 256); > - > - *unsigned_flag = 0; > - > - switch (field->key_type()) { > - case HA_KEYTYPE_USHORT_INT: > - case HA_KEYTYPE_ULONG_INT: > - case HA_KEYTYPE_UINT24: > - case HA_KEYTYPE_ULONGLONG: > + DBUG_ASSERT((ulint)MYSQL_TYPE_STRING < 256); > + DBUG_ASSERT((ulint)MYSQL_TYPE_VAR_STRING < 256); > + DBUG_ASSERT((ulint)MYSQL_TYPE_DOUBLE < 256); > + DBUG_ASSERT((ulint)MYSQL_TYPE_FLOAT < 256); > + DBUG_ASSERT((ulint)MYSQL_TYPE_DECIMAL < 256); > + > + if (field->flags & UNSIGNED_FLAG) { > + > *unsigned_flag = DATA_UNSIGNED; > - /* fall through */ > - case HA_KEYTYPE_SHORT_INT: > - case HA_KEYTYPE_LONG_INT: > - case HA_KEYTYPE_INT24: > - case HA_KEYTYPE_INT8: > - case HA_KEYTYPE_LONGLONG: > + } else { > + *unsigned_flag = 0; > + } > + > + if (field->real_type() == MYSQL_TYPE_ENUM > + || field->real_type() == MYSQL_TYPE_SET) { > + > + /* MySQL has field->type() a string type for these, but the > + data is actually internally stored as an unsigned integer > + code! */ > + > + *unsigned_flag = DATA_UNSIGNED; /* MySQL has its own unsigned > + flag set to zero, even though > + internally this is an unsigned > + integer type */ > return(DATA_INT); > - case HA_KEYTYPE_FLOAT: > - return(DATA_FLOAT); > - case HA_KEYTYPE_DOUBLE: > - return(DATA_DOUBLE); > - case HA_KEYTYPE_BINARY: > - if (field->type() == MYSQL_TYPE_TINY || > - field->real_type() == MYSQL_TYPE_ENUM || > - field->real_type() == MYSQL_TYPE_SET > - ) > - { // compatibility workaround > - *unsigned_flag= DATA_UNSIGNED; > - return DATA_INT; > - } > - return(DATA_FIXBINARY); > - case HA_KEYTYPE_VARBINARY2: > - if (field->type() != MYSQL_TYPE_VARCHAR) > - return(DATA_BLOB); > - /* fall through */ > - case HA_KEYTYPE_VARBINARY1: > - return(DATA_BINARY); > - case HA_KEYTYPE_VARTEXT2: > - if (field->type() != MYSQL_TYPE_VARCHAR) > - return(DATA_BLOB); > - /* fall through */ > - case HA_KEYTYPE_VARTEXT1: > - if (field->charset() == &my_charset_latin1) { > + } > + > + switch (field->type()) { > + /* NOTE that we only allow string types in DATA_MYSQL and > + DATA_VARMYSQL */ > + case MYSQL_TYPE_VAR_STRING: /* old <= 4.1 VARCHAR */ > + case MYSQL_TYPE_VARCHAR: /* new >= 5.0.3 true VARCHAR */ > + if (field->binary()) { > + return(DATA_BINARY); > + } else if (strcmp(field->charset()->name, > + "latin1_swedish_ci") == 0) { > return(DATA_VARCHAR); > } else { > return(DATA_VARMYSQL); > } > - case HA_KEYTYPE_TEXT: > - if (field->charset() == &my_charset_latin1) { > + case MYSQL_TYPE_BIT: > + case MYSQL_TYPE_STRING: if (field->binary()) { > + > + return(DATA_FIXBINARY); > + } else if (strcmp(field->charset()->name, > + "latin1_swedish_ci") == 0) { > return(DATA_CHAR); > } else { > return(DATA_MYSQL); > } > - case HA_KEYTYPE_NUM: > + case MYSQL_TYPE_NEWDECIMAL: > + return(DATA_FIXBINARY); > + case MYSQL_TYPE_LONG: > + case MYSQL_TYPE_LONGLONG: > + case MYSQL_TYPE_TINY: > + case MYSQL_TYPE_SHORT: > + case MYSQL_TYPE_INT24: > + case MYSQL_TYPE_DATE: > + case MYSQL_TYPE_YEAR: > + case MYSQL_TYPE_NEWDATE: > + return(DATA_INT); > + case MYSQL_TYPE_TIMESTAMP: > + *unsigned_flag = 0; > + /* fall through */ > + case MYSQL_TYPE_TIME: > + case MYSQL_TYPE_DATETIME: > + if (field->key_type() == HA_KEYTYPE_BINARY) > + return(DATA_FIXBINARY); > + else > + return(DATA_INT); > You also need to support MYSQL_TYPE_{TIMESTAMP,TIME,DATETIME}2 for MySQL 5.6 here. > + case MYSQL_TYPE_FLOAT: > + return(DATA_FLOAT); > + case MYSQL_TYPE_DOUBLE: > + return(DATA_DOUBLE); > + case MYSQL_TYPE_DECIMAL: > return(DATA_DECIMAL); > - case HA_KEYTYPE_BIT: > - case HA_KEYTYPE_END: > + case MYSQL_TYPE_GEOMETRY: > + case MYSQL_TYPE_TINY_BLOB: > + case MYSQL_TYPE_MEDIUM_BLOB: > + case MYSQL_TYPE_BLOB: > + case MYSQL_TYPE_LONG_BLOB: > + return(DATA_BLOB); > + case MYSQL_TYPE_NULL: > + /* MySQL currently accepts "NULL" datatype, but will > + reject such datatype in the next release. We will cope > + with it and not trigger assertion failure in 5.1 */ > + break; > + default: > ut_error; > } > > === modified file 'storage/innobase/handler/handler0alter.cc' > --- storage/innobase/handler/handler0alter.cc 2013-09-21 08:14:42 +0000 > +++ storage/innobase/handler/handler0alter.cc 2013-11-11 20:54:09 +0000 > @@ -347,6 +347,32 @@ > } > } > > + /* > + InnoDB in different MariaDB versions was generating different > mtype > + codes for certain types. Also signed/unsigned bit was generated > + differently too. > It may be more clear to merge these two sentences into one. > + > + Online ALTER would change the mtype/unsigned_flag (to what the > + current code generates) without changing the underlying data > + represenation, and it might result in data corruption. > + > + Don't do online ALTER if mtype/unsigned_flag are wrong. > + */ > + for (ulint i = 0; i < table->s->fields; i++) { > + const Field* field = table->field[i]; > + const dict_col_t* col = dict_table_get_nth_col(prebuilt->table, i); > + ulint unsigned_flag; > + if (col->mtype != get_innobase_type_from_mysql_type(&unsigned_flag, > field)) { > + > + DBUG_RETURN(HA_ALTER_INPLACE_NOT_SUPPORTED); > + } > + > + if ((col->prtype & DATA_UNSIGNED) != unsigned_flag) { > + > + DBUG_RETURN(HA_ALTER_INPLACE_NOT_SUPPORTED); > + } > + } > + > This looks reasonable to me. > /* We should be able to do the operation in-place. > See if we can do it online (LOCK=NONE). */ > bool online = true;

2 4

Re: [Maria-developers] maria-tokudb-engine-10.0 deb package (raring) - if files are empty where are sources?
by Sergei Golubchik 15 Nov '13

15 Nov '13

Hi, Jocelyn! On Nov 14, Jocelyn Fournier wrote: > Hi, > > Perhaps it would be great to mention in the 10.0.5 download page it's > not yet compatible with TokuDB. > I've tried myself to upgrade my server using MariaDB 5.5.33a with tokudb > to 10.0.5 and it failed because of this issue. I believe, only deb packages are affected. TokuDB is present in rpms, in the source and in the binary tarballs. But I see you point, we'll probably add some warning, thanks! Regards, Sergei

2 1

Re: [Maria-developers] MDEV-5220 - [PATCH] MariaDB 10.0.4 doesn't compile without perfschema
by Sergei Golubchik 14 Nov '13

14 Nov '13

Hi, Sergey! Generally, it's ok, of course. But as a matter of style (up to you to fix it here, but keep in mind for the future) - see below On Nov 13, Sergey Vojtovich wrote: > === modified file 'sql/mysqld.cc' > --- a/sql/mysqld.cc 2013-11-01 11:00:11 +0000 > +++ b/sql/mysqld.cc 2013-11-13 07:07:55 +0000 > @@ -760,6 +760,7 @@ char **orig_argv; > > static struct my_option pfs_early_options[] __attribute__((unused)) = I suppose, we don't need __attribute__((unused)) here, if the array is used unconditionally. > { > +#ifdef WITH_PERFSCHEMA_STORAGE_ENGINE > {"performance_schema_instrument", OPT_PFS_INSTRUMENT, > "Default startup value for a performance schema instrument.", > &pfs_param.m_pfs_instrument, &pfs_param.m_pfs_instrument, 0, GET_STR, > @@ -824,6 +825,7 @@ static struct my_option pfs_early_option > &pfs_param.m_consumer_statement_digest_enabled, > &pfs_param.m_consumer_statement_digest_enabled, 0, > GET_BOOL, OPT_ARG, TRUE, 0, 0, 0, 0, 0} > +#endif /* WITH_PERFSCHEMA_STORAGE_ENGINE */ > }; > > #ifdef HAVE_PSI_INTERFACE > @@ -1146,7 +1148,6 @@ void net_after_header_psi(struct st_net > > void init_net_server_extension(THD *thd) > { > -#ifdef HAVE_PSI_INTERFACE > /* Start with a clean state for connection events. */ > thd->m_idle_psi= NULL; > thd->m_statement_psi= NULL; > @@ -1157,9 +1158,6 @@ void init_net_server_extension(THD *thd) > thd->m_net_server_extension.m_after_header= net_after_header_psi; > /* Activate this private extension for the mysqld server. */ > thd->net.extension= & thd->m_net_server_extension; > -#else > - thd->net.extension= NULL; > -#endif > } > #endif /* EMBEDDED_LIBRARY */ > > @@ -4397,7 +4395,9 @@ static int init_thread_environment() > #ifdef HAVE_EVENT_SCHEDULER > Events::init_mutexes(); > #endif > +#ifdef HAVE_PSI_INTERFACE > init_show_explain_psi_keys(); > +#endif I usually define an no-op function and use it unconditionally, to avoid scattering #ifdefs in the code. > /* Parameter for threads created for connections */ > (void) pthread_attr_init(&connection_attrib); > (void) pthread_attr_setdetachstate(&connection_attrib, > @@ -5137,9 +5137,12 @@ int mysqld_main(int argc, char **argv) > buffered_logs.init(); > my_getopt_error_reporter= buffered_option_error_reporter; > my_charset_error_reporter= buffered_option_error_reporter; > +#ifdef WITH_PERFSCHEMA_STORAGE_ENGINE > pfs_param.m_pfs_instrument= const_cast<char*>(""); > > - int ho_error= handle_early_options(); > + int ho_error= > +#endif /* WITH_PERFSCHEMA_STORAGE_ENGINE */ > + handle_early_options(); Please, don't #ifdef part of a statement. Here I'd use __attribute__((unused)) to suppress a compiler warning. > #ifdef WITH_PERFSCHEMA_STORAGE_ENGINE > if (ho_error == 0) > Regards, Sergei

2 1

[Maria-developers] Thoughts on a variable to control high resolution temporal type format and rounding behavior?
by Jeremy Cole 14 Nov '13

14 Nov '13

Sergei, In the process of working through the bugs I've reported re. time formats and InnoDB storage formats we noted that there isn't currently any way to cause MariaDB to create a *new* Oracle MySQL 5.6-format TIMESTAMP/TIME/DATETIME field, and thus there's not really very good test coverage of them. Additionally the existence of this difference relative to Oracle MySQL is not really desirable. I would propose adding a new sysvar to control the temporal time format e.g. temporal_microsecond_format={mysql|mariadb} which controls whether newly created columns are created as Field_*_hires or Field_*f. This would especially allow: 1. Tests to be run in both Oracle MySQL and MariaDB modes. 2. A single test to create a column in one format and request conversion to the other. 3. A user to convert the format of their existing tables for compatibility. Additionally I would suggest a new sysvar to control the rounding behavior of the same temporal types, e.g. temporal_microsecond_rounding={round|truncate} which controls whether to round (as Oracle MySQL 5.6 does) or to truncate (as MariaDB does) when faced with fitting a larger number of decimals in a value into a smaller number decimals in a field. (This of course assumes that the current MariaDB behavior and divergence from Oracle MySQL behavior is intentional, and not a bug. Even if it is considered a bug it could probably not be changed outright at this point and the sysvar would still be needed.) Any thoughts on either of these? We would of course be willing to do the work and provide the patches for them. I just wanted to get your general feelings on the ideas. Regards, Jeremy

3 6

[Maria-developers] EXPLAIN in the slow query log
by Sergei Petrunia 12 Nov '13

12 Nov '13

Hello, After recent changes in the [SHOW] EXPLAIN architecture in MariaDB, it became really easy to add an option to print EXPLAIN(*) output into the slow query log, so I went ahead and implemented it. @@log_slow_verbosity has got a 'explain' flag, and if it is on, the slow query log entries look like this: # Time: 131017 21:26:02 # User@Host: root[root] @ localhost [] # Thread_id: 2 Schema: dbt3sf1 QC_hit: No # Query_time: 5.535819 Lock_time: 0.000350 Rows_sent: 1 Rows_examined: 65633 ## <explain> ## id select_type table type possible_keys key key_len ref rows Extra ## 1 SIMPLE nation ref PRIMARY,n_name n_name 26 const 1 Using where; Using index ## 1 SIMPLE customer ref PRIMARY,i_c_nationkey i_c_nationkey 5 dbt3sf1.nation.n_nationkey 25124 Using index ## 1 SIMPLE orders ref i_o_custkey i_o_custkey 5 dbt3sf1.customer.c_custkey 7 Using index ## </explain> SET timestamp=1382030762; select count(*) from customer, orders, nation where c_custkey=o_custkey and c_nationkey=n_nationkey and n_name='GERMANY'; It seems, pt-slow-query-log has no problem parsing this. Open questions: - Is this syntax OK? - Currently, some statements (like SHOW KEYS) print a dumb explain that shows that full table scan is used. There is a suggestion to not print EXPLAIN for any SHOW statements. Is this ok? (*) something like EXPLAIN ANALYZE, with numbers from actual execution, would be better but we are not there yet. BR Sergei -- Sergei Petrunia, Software Developer MariaDB | Skype: sergefp | Blog: http://s.petrunia.net/blog

5 6

[Maria-developers] A newer InnoDB in 10.0 series?
by Colin Charles 12 Nov '13

12 Nov '13

Hi! I see that we are shipping InnoDB from 5.6.5 (at least that's what the plugin version tells me - 1.2.5). Are we going to pop XtraDB or a modern InnoDB into 10.0.6? Thanks -- Colin Charles, Chief Evangelist MariaDB | t: +6-012-204-3201 | Skype: colincharles

3 3

Re: [Maria-developers] [Commits] Rev 3886: MDEV-4439 ALTER TABLE .. [ADD|DROP] FOREIGN KEY IF [NOT] EXISTS does not work if constraint name is not used. in file:///home/hf/wmar/10exp/
by Jan Lindström 11 Nov '13

11 Nov '13

Hi, MySQL changes look good, InnoDB changes need some work that I will do, please do not push those. R: Jan > At file:///home/hf/wmar/10exp/ > > ------------------------------------------------------------ > revno: 3886 > revision-id: holyfoot(a)askmonty.org-20131108110551-j0rxpxrnfertay2q > parent: knielsen(a)knielsen-hq.org-20131107065240-gxxg4ilcs8o2v0q2 > committer: Alexey Botchkov <holyfoot(a)askmonty.org> > branch nick: 10exp > timestamp: Fri 2013-11-08 15:05:51 +0400 > message: > MDEV-4439 ALTER TABLE .. [ADD|DROP] FOREIGN KEY IF [NOT] EXISTS does not work if constraint name is not used. > Patches for server and the Innodb engine. > Server is fixed so it does nothing if no indexes left to alter. > Innodb parser is fixed so it looks for the IF [NOT] EXISTS option, > another change is that it uses the index name for the internal dictionary. > Prior to that it only used the CONSTRAINT name for it. > > > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits -- -- Jan Lindström Principal Engineer MariaDB | MaxScale | skype: jan_p_lindstrom www.skysql.com <http://www.skysql.com/> Twitter <http://twitter.com/skysql> Blog <http://www.skysql.com/blog/> Facebook <http://www.facebook.com/skysql> LinkedIn <http://www.linkedin.com/company/1214250> Google+ <https://plus.google.com/117544963211695643458/posts>

1 0

Re: [Maria-developers] patch to upgrade collations
by Michael Widenius 09 Nov '13

09 Nov '13

Hi! >>>>> "Alexander" == Alexander Barkov <bar(a)mariadb.org> writes: Alexander> Hi Monty, Alexander> Please find the full patch attached. Alexander> Greetings. Here is a modified patch that also fixes that REPAIR works. It doesn't include the myisam files that you had in your patch, but it will of course need these. I have verified that all test cases you changed works. Regards, Monty

1 0

[Maria-developers] MDEV-4954
by Sergei Golubchik 09 Nov '13

09 Nov '13

Hi, Oden could you please take a look at MDEV-4954? https://mariadb.atlassian.net/browse/MDEV-4954 "RPM Packaging Removes Config File" The complain is that when one uninstalls MariaDB, /etc/my.cnf gets "removed" (actually, renamed to /etc/my.cnf.rpmsave). And MySQL packages don't do that (because they don't include my.cnf at all). Anything we can do to make the user happier? Regards, Sergei

1 0

[Maria-developers] Debian/Ubuntu packages
by Matt Coleman 07 Nov '13

07 Nov '13

Hello, I’m working on fixing the dependency issues with MariaDB 5.5.33a vs MySQL 5.5.34. When I’m ready to publish my fix, what version number should I give it? The current packages have the version 5.5.33a+maria-1~CODENAME, where CODENAME is the code name for the Debian or Ubuntu release (ie. “sid” or “precise”, etc). Since I am not changing any code, it seems like like 5.5.33a should remain the same. I expected that the fixed package would be 5.5.33a+maria-2~CODENAME, but autobake-deb.sh assembles that version string and the 1 is hardcoded, not set by a variable. The two variables RELEASE_NAME and RELEASE_EXTRA can insert text between “+maria-“ and “1”. What is this project’s versioning convention in regards to changes that only affect the packaging? Matt

2 2

Re: [Maria-developers] [Commits] Rev 3942: MDEV-5205 - MariaDB does not start if more than 128 cpu's are available
by Sergei Golubchik 07 Nov '13

07 Nov '13

Hi, Sergey! On Nov 06, Sergey Vojtovich wrote: > ------------------------------------------------------------ > revno: 3942 > revision-id: svoj(a)mariadb.org-20131106185339-wjz3xuru8ojnz00l > parent: monty(a)askmonty.org-20131105183036-051tak9a2fq9ii05 > committer: Sergey Vojtovich <svoj(a)mariadb.org> > branch nick: 5.5-mdev5205 > timestamp: Wed 2013-11-06 22:53:39 +0400 > message: > MDEV-5205 - MariaDB does not start if more than 128 cpu's are available > > An addition to fix for MDEV-5205, fixes server crash on shutdown. > > Thread groups are destroyed asynchronously, that is kill server > thread sends shutdown request to all thread groups without waiting > for compeltion. > > It means all_groups array must not be freed until all thread groups > are down. This patch suggests that all_groups is freed when last > thread group is destroyed. Looks reasonable. ok to push Regards, Sergei

1 0

[Maria-developers] MariaDB 10.0.5 Beta Release Prep
by Daniel Bartholomew 06 Nov '13

06 Nov '13

I'm currently in the process of preparing for the MariaDB 10.0.5 Beta release. Draft changelog and release notes are here: - https://mariadb.com/kb/en/mariadb-1005-release-notes/ - https://mariadb.com/kb/en/mariadb-1005-changelog/ The release notes page is not much more than a template at present and needs to be be filled in before the release. Please add any items that should be there ASAP. Current plans are to activate and announce the release tomorrow (6 Nov). Thanks. -- Daniel Bartholomew MariaDB

1 0

[Maria-developers] Opened_plugin_libraries status variable
by Ian Gilfillan 05 Nov '13

05 Nov '13

Hi I would like to document the Opened_plugin_libraries status variable, introduced in MariaDB 10.0, but can't understand what it's all about. I have looked at: http://lists.askmonty.org/pipermail/commits/2013-April/004595.html but it's not really making sense what it's testing. In my own setup, each time I query the INFORMATION_SCHEMA.ALL_PLUGINS table, Opened_plugin_libraries increments by 19 (no matter what conditions I apply). The only correlation I can find is that there are 19 records with the LOAD_OPTION = 'OFF'. Is this what Opened_plugin_libraries is recording? Why does it increment each time I query the table (19, 38, 57 etc) - how is this useful? Can someone clarify exactly what this variable records, and how it's useful? thanks, ian

2 1

[Maria-developers] On how to fix indentation and history in sql_join_cache.cc
by Sergei Petrunia 05 Nov '13

05 Nov '13

Hi Sanja, My experiment was successfull. It seems, one can fix identation in sql_join_cache.cc so in the following way: # Create a branch in a state "right after the problem" bzr branch -rsanja(a)askmonty.org-20121223213711-ac5vz2fspwapjvtr 10.0 work-maria-10.0-base-cassandra-look1 # The -r3457 branch shows the state "right before the merge that borked it" bzr branch -r3457 work-maria-10.0-base-cassandra-look1 work-maria-10.0-base-cassandra-look1-r3457 cd work-maria-10.0-base-cassandra-look1-r3457 # Do some dummy change to force a merge gvim sql/sql_join_cache.cc bzr gcommit # Prepare the branch where we will fix it cd .. bzr branch work-maria-10.0-base-cassandra-look1 work-maria-10.0-base-cassandra-look1-cp cd work-maria-10.0-base-cassandra-look1-cp # This should show that you're going to merge the dummy change bzr missing --theirs-only ../work-maria-10.0-base-cassandra-look1-r3457/ # # This will will succeed without conflicts. We will use this merge as an # excuse to fix the problem # bzr merge --pull ../work-maria-10.0-base-cassandra-look1-r3457/ # # Now, edit the "broken" file and the original file until sql/sql_join_cache.cc # is ok # gvimdiff ~/home/psergey/dev2/work-maria-10.0-base-cassandra-look1-r3457/sql/sql_join_cache.cc sql/sql_join_cache.cc # Commit bzr gcommit # # Merge the change into a recent 10.0-base. # cd 10.0-base bzr merge --pull ../work-maria-10.0-base-cassandra-look1-cp/ bzr gcommit # # Check the history. It MUST NOT show any of today's merges. # the code in bkah_skip_index_tuple() should show that lines belong to # # igor(a)askmonty.org-20100831163421-iiddbral4jr3q75q # The main patch for MWL#128: Implement Block Nested Loop Hash Join. # # sanja(a)montyprogram.com-20120216064910-k0ud8ja7ef1jnpx4 # Counters for Index Condition Pushdown added (MDEV-130). bzr gannotate sql/sql_join_cache.cc BR Sergei -- Sergei Petrunia, Software Developer MariaDB | Skype: sergefp | Blog: http://s.petrunia.net/blog

2 2

[Maria-developers] Preparing MDEV-4506, Parallel replication, for 10.0.5 release
by Kristian Nielsen 04 Nov '13

04 Nov '13

Hi Monty, I was asked to prepare MDEV-4506, parallel replication, for release of 10.0.5 on Monday. For this, I did merge to 10.0-base and then to 10.0. I have pushed the results here: lp:~maria-captains/maria/mdev-4506-base # for 10.0-base merge lp:~maria-captains/maria/mdev-4506 # for 10.0 merge However, I had problems with a couple of your changes, to temporary tables and innodb log file size. The code that you modified in 10.0-base does not seem to exist in 10.0 (or at least I couldn't find it easily). Can you take a look at this and see if you can complete the merge? The missing bits are just the few hunks appended at the end of this mail, so I assume it should be easy for someone who knows what the patches are supposed to do. The tree lp:~maria-captains/maria/mdev-4506 currently has a lot of test failures, but it looks like most of them will be fixed by completing the last bits of the merge. - Kristian. ----------------------------------------------------------------------- sql/sql_base.cc: <<<<<<< TREE if (table_list->mdl_request.type >= MDL_SHARED_WRITE && thd->tx_read_only && !(flags & (MYSQL_LOCK_LOG_TABLE | MYSQL_OPEN_HAS_MDL_LOCK))) ||||||| BASE-REVISION if (table_list->open_type != OT_BASE_ONLY && ! (flags & MYSQL_OPEN_SKIP_TEMPORARY)) ======= if (table_list->open_type != OT_BASE_ONLY && ! (flags & MYSQL_OPEN_SKIP_TEMPORARY) && thd->have_temporary_tables()) >>>>>>> MERGE-SOURCE { <<<<<<< TREE my_error(ER_CANT_EXECUTE_IN_READ_ONLY_TRANSACTION, MYF(0)); DBUG_RETURN(true); ||||||| BASE-REVISION for (table= thd->temporary_tables; table ; table=table->next) { if (table->s->table_cache_key.length == key_length + TMP_TABLE_KEY_EXTRA && !memcmp(table->s->table_cache_key.str, key, key_length + TMP_TABLE_KEY_EXTRA)) { /* We're trying to use the same temporary table twice in a query. Right now we don't support this because a temporary table is always represented by only one TABLE object in THD, and it can not be cloned. Emit an error for an unsupported behaviour. */ if (table->query_id) { DBUG_PRINT("error", ("query_id: %lu server_id: %u pseudo_thread_id: %lu", (ulong) table->query_id, (uint) thd->variables.server_id, (ulong) thd->variables.pseudo_thread_id)); my_error(ER_CANT_REOPEN_TABLE, MYF(0), table->alias.c_ptr()); DBUG_RETURN(TRUE); } table->query_id= thd->query_id; thd->thread_specific_used= TRUE; DBUG_PRINT("info",("Using temporary table")); goto reset; } } ======= if ((table= find_temporary_table(thd, key, key_length + TMP_TABLE_KEY_EXTRA))) { /* Check if we're trying to use the same temporary table twice in a query. Right now we don't support this because a temporary table is always represented by only one TABLE object in THD, and it can not be cloned. Emit an error for an unsupported behaviour. */ if (table->query_id) { DBUG_PRINT("error", ("query_id: %lu server_id: %u pseudo_thread_id: %lu", (ulong) table->query_id, (uint) thd->variables.server_id, (ulong) thd->variables.pseudo_thread_id)); my_error(ER_CANT_REOPEN_TABLE, MYF(0), table->alias.c_ptr()); DBUG_RETURN(TRUE); } table->query_id= thd->query_id; thd->thread_specific_used= TRUE; DBUG_PRINT("info",("Using temporary table")); goto reset; } >>>>>>> MERGE-SOURCE sql/slave.cc: <<<<<<< TREE static void set_thd_in_use_temporary_tables(Relay_log_info *rli) { TABLE *table; for (table= rli->save_temporary_tables ; table ; table= table->next) { table->in_use= rli->sql_thd; if (table->file != NULL) { /* Since we are stealing opened temporary tables from one thread to another, we need to let the performance schema know that, for aggregates per thread to work properly. */ table->file->unbind_psi(); table->file->rebind_psi(); } } } ||||||| BASE-REVISION static void set_thd_in_use_temporary_tables(Relay_log_info *rli) { TABLE *table; for (table= rli->save_temporary_tables ; table ; table= table->next) table->in_use= rli->sql_thd; } ======= >>>>>>> MERGE-SOURCE === modified file 'storage/innobase/srv/srv0start.c' --- storage/innobase/srv/srv0start.c 2013-09-06 20:31:30 +0000 +++ storage/innobase/srv/srv0start.c 2013-11-01 08:17:06 +0000 @@ -621,7 +621,7 @@ open_or_create_log_file( || size_high != srv_calc_high32(srv_log_file_size)) { fprintf(stderr, - "InnoDB: Error: log file %s is" + "InnoDB: Warning: log file %s is" " of different size %lu %lu bytes\n" "InnoDB: than specified in the .cnf" " file %lu %lu bytes!\n", @@ -629,7 +629,8 @@ open_or_create_log_file( (ulong) srv_calc_high32(srv_log_file_size), (ulong) srv_calc_low32(srv_log_file_size)); - return(DB_ERROR); + srv_log_file_size= size + + (((longlong) size_high) << 32); } } else { *log_file_created = TRUE;

2 3

Re: [Maria-developers] MDEV-5205 - MariaDB does not start if more than 128 cpu's are available
by Sergei Golubchik 02 Nov '13

02 Nov '13

Hi, Sergey! On Nov 01, Sergey Vojtovich wrote: > revno: 3939 > revision-id: svoj(a)mariadb.org-20131101154841-egjkqc4e00mxc3ty > parent: sanja(a)montyprogram.com-20131029165036-f4wqcr2nrxzuwuuv > committer: Sergey Vojtovich <svoj(a)mariadb.org> > branch nick: 5.5-mdev5205 > timestamp: Fri 2013-11-01 19:48:41 +0400 > message: > MDEV-5205 - MariaDB does not start if more than 128 cpu's are available > > === modified file 'sql/threadpool_unix.cc' > --- a/sql/threadpool_unix.cc 2013-06-22 12:02:03 +0000 > +++ b/sql/threadpool_unix.cc 2013-11-01 15:48:41 +0000 > @@ -907,6 +907,7 @@ int thread_group_init(thread_group_t *th > thread_group->pollfd= -1; > thread_group->shutdown_pipe[0]= -1; > thread_group->shutdown_pipe[1]= -1; > + thread_group->queue.empty(); ok, but please add to the definition of I_P_List::empty() a comment that it's used in many places in the code instead of a constructor, to initialize a bzero-ed I_P_List instance. > DBUG_RETURN(0); > } > Regards, Sergei

1 0

[Maria-developers] doubt, Got a packet bigger than 'max_allowed_packet' bytes - 1153
by Roberto Spadim 01 Nov '13

01 Nov '13

Hi guys, i'm with a doubt now... using the php extension of mysql i got this error Got a packet bigger than 'max_allowed_packet' bytes - 1153 the point is... should the client api change the packet to a size smaller than max limit? or should i set the max_allowed_packet at server side? this variable have some memory problem if changed to a big value? today i'm using 1MB, but i don't know if i change for example to 1024MB i could break the server, does the max_allowed_packet just a limit, or a malloc parameter to alloc memory at each packet? -- Roberto Spadim SPAEmpresarial

1 1

Re: [Maria-developers] MWL83: review
by Sergei Petrunia 31 Oct '13

31 Oct '13

Hi Timour, Found another possible issue: The code in best_extension_by_limited_search() calls join->static_pushdown_cost(). static_pushdown_cost() may modify join->position[$I].read_time for any $I. Now, consider an example: SELECT * FROM t1,t2,t3 WHERE subquery_conditions The join optimizer will consider join orders: S1: t1 S2: t1 t2 S3: t1 t2 t3 S4: t1 t3 t2 On step S3, we will get a complete join order, and the new code in best_extension_by_limited_search() is invoked. It will call join->static_pushdown_cost(...) which may change the value of join->position[0].read_time On step S4, we again will get a complete join order. The new code in best_extension_by_limited_search() is invoked, it will call join->static_pushdown_cost(...), which again may change join->position[0].read_time Now, that value will be meaningless. BR Sergei -- Sergei Petrunia, Software Developer MariaDB | Skype: sergefp | Blog: http://s.petrunia.net/blog

1 0

Re: [Maria-developers] [Commits] Rev 3711: MDEV-5104 crash in Item_field::used_tables with broken order by in file:///home/tsk/mprog/src/5.3/
by Oleksandr Byelkin 29 Oct '13

29 Oct '13

Hi! OK to push! Thank you! 29.10.2013 12:39, timour(a)askmonty.org пишет: > At file:///home/tsk/mprog/src/5.3/ > > ------------------------------------------------------------ > revno: 3711 > revision-id: timour(a)askmonty.org-20131029103903-bvjnf3b2aqnoyut5 > parent: sanja(a)askmonty.org-20131021104549-857lwynmy813qyd4 > fixes bug: https://mariadb.atlassian.net/browse/MDEV-5104 > committer: timour(a)askmonty.org <timour(a)askmonty.org> > branch nick: 5.3 > timestamp: Tue 2013-10-29 12:39:03 +0200 > message: > MDEV-5104 crash in Item_field::used_tables with broken order by > > Analysis: > st_select_lex_unit::prepare() computes can_skip_order_by as TRUE. > As a result join->prepare() gets called with order == NULL, and > doesn't do name resolution for the inner ORDER clause. Due to this > the prepare phase doesn't detect that the query references non-exiting > function and field. > > Later join->optimize() calls update_used_tables() for a non-resolved > Item_field, which understandably has no Field object. This call results > in a crash. > > Solution: > Resolve unnecessary ORDER BY clauses to detect if they reference non-exising > objects. Then remove such clauses from the JOIN object. > > > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits

1 0