November 2013 - developers - lists.mariadb.org

[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 … [View More]

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 … [View More]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. [View Less]

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 … [View More]

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 … [View More]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; [View Less]

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, … [View More]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 [View Less]

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. … [View More]

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: … [View More]

5 6