- developers - lists.mariadb.org

[Maria-developers] MDEV-9541 Selecting a time using a datetime fails
by Alexander Barkov 12 Feb '16

12 Feb '16

Hi Monty, Please have a look into the latest comments in MDEV-9541 on how PostgreSQL, SQL Server, Oracle 11i and MySQL-5.7 work when comparing temporal data types. There is no a general rule. Every vendor implements it in a different way. 1. PostgreSQL almost follows the standard, which disallows direct comparison of TIME and TIMESTAMP/DATETIME. The only exception, it allows to compare a TIME field to a string literal which looks like TIMESTAMP: SELECT * FROM t1 WHERE a='2001-01-01 10:20:30'; a | b ----------+--------------------- 10:20:30 | 2001-01-01 10:20:30 But strangely not the other way around! Comparing of a TIMESTAMP field to a string which looks like TIME does not work. I did not find an explanation for this. 2. SQL Server - Comparison of TIME + VARCHAR is done as TIME - Comparison of DATETIME + VARCHAR is done as DATETIME - Comparison of TIME and DATETIME is not allowed - Comparison of TIME and INT is not allowed - Comparison of DATETIME and INT is allowed (not sure how exactly it works though) - Temporal literals {t'10:20:30'} have data type VARCHAR, this is just a syntactic variation of a string literal '10:20:30', with no any additional difference. 3. Oracle 11i Oracle does not have the TIME data type. So mixture of TIME and TIMESTAMP is not possible. But comparison of TIMESTAMP and VARCHAR is always done as TIMESTAMP, no matter what kind expressions are involved (fields, functions, literals). 4. MySQL-5.7 It has a special code: for a TIME field compared to a non-DATE constant, the constant argument is converted to TIME. But as soon as you wrap the field say into COALESCE, or put a non-constant instead of a constant, this works in a different way. So, comparing of a TIME field to a string literal that looks like a TIMESTAMP/DATETIME works similar in PostgreSQL, SQL Server, MySQL-5.7. However, this looks only as a coincidence for this particular corner case. Perhaps we should not fix that in 10.0. It seems that MariaDB since 5.3 handles comparison of TIME in a more consistent way (less exceptions). Btw, why not to add a warning every time when an implicit non-standard type conversion happens and suggest an explicit CAST? This will encourage users to avoid doubtful constructions. Also, I noticed that the SQL Server documentation says that comparison of different data types is a subject to change in the future versions, and using this is not recommended. Perhaps we should also say something like this. I propose instead of adding a quick fix for this exception, to introduce a conception of "type strength" or "type derivation" in 10.2. The idea is simple: 1. Comparison is done according to the type of the strongest side. 2. Strengths(derivations) are as follows: - A field or an SP variable has the strongest type derivation, say 4. - Functions have derivation between field and typified constants, say 3. - Some functions that return input arguments (e.g. COALESCE, LEFT) can repeat derivations of their arguments. - A typified constant like TIME'10:20:30' has derivation 2. - A typeless constant like '10:20:30' has a very weak derivation, say 1. - An explicit NULL has the weakest derivation, say 0. 3. Only in case of equal strengths the result depends on the data types. Perhaps data types can have some sort of "minor strength", for conflict resolution. Say DATETIME/TIMESTAMP can have more minor strength over TIME or DATE. So a DATETIME field is compared to a TIME field as DATETIME rather than TIME. This will give some advantages: - Universal comparison rules for all data types - This idea will simplify adding new data types a lot. They will just follow the universal rule. Otherwise, new data types (say INET6), we'll have to have different execution paths with some exceptions and exceptions from exceptions :) - The problem mentioned in MDEV-9541 will be gone: it will compare as TIME just because it's a field compared to a typeless constant. - We'll remove a special code covering comparison of YEAR and LONGLONG fields. They will just work as before, but now because a field always wins a constant, according to the universal rules. - We'll probably remove some examples of a special code covering explicit NULLs (i.e. Item::NULL_ITEM). - A field compared to a constant will always be able to use indexes. Less chances to put the server into a heavy load because of a non-smart query executed. - The same results for a field compared to some expression, and for the same field wrapped into a hybrid function like COALESCE. - Hybrid functions with field arguments will also be able to use indexes in some cases. - Equal field propagation will be possible in more cases. - It should be easier to add a new SQL mode for the strict SQL standard compliant comparison style. I think it's good to have this option. Greetings.

1 0

[Maria-developers] MDEV-9371 select insert('a', 2, 1, 'b') doesn't return expected 'a'
by Alexander Barkov 10 Feb '16

10 Feb '16

Hello Sergei, Please review a fix for MDEV-9371. I'd suggest to push it to 10.0 instead of 5.5, as MySQL fixed this bug in 5.6 (not 5.5). Also, I think it's worthy to backport MDEV-9332 to 10.0 as well, because the patch for MDEV-9371 touches the test which we modified in MDEV-9332. Thanks!

2 2

Re: [Maria-developers] [Commits] 841c317: MDEV-7122: Assertion `0' failed in subselect_hash_sj_engine::init
by Sergey Petrunia 09 Feb '16

09 Feb '16

Hi Vicentiu, Please find some cosmetic feedback below. Ok to push after it is addressed. On Tue, Feb 09, 2016 at 04:02:58PM +0200, Vicentiu Ciorbaru wrote: > revision-id: 841c317d237453f3e6c253e2a884cad73622b59a (mariadb-5.5.47-33-g841c317) > parent(s): ad94790f468bacb2cd62d02d3a6e7f012ca72e65 > author: Vicențiu Ciorbaru > committer: Vicențiu Ciorbaru > timestamp: 2016-02-09 16:00:18 +0200 > message: > > MDEV-7122: Assertion `0' failed in subselect_hash_sj_engine::init > > The select mentioned in the bug attempted to create a temporary table > using the maria storage engine. The table needs to have primary keys such that > duplicates can be removed. Unfortunately this use case has a longer > than allowed key and the tmp table got created without a temporary key. > We must not allow materialization for the subquery if the total key > length and key parts is greater than what the storage engine supports. > > --- > mysql-test/r/subselect.result | 12 ++++++++++++ > mysql-test/r/subselect_no_mat.result | 12 ++++++++++++ > mysql-test/r/subselect_no_opts.result | 12 ++++++++++++ > mysql-test/r/subselect_no_scache.result | 12 ++++++++++++ > mysql-test/r/subselect_no_semijoin.result | 12 ++++++++++++ > mysql-test/t/subselect.test | 9 +++++++++ > sql/opt_subselect.cc | 10 ++++++++++ > sql/sql_select.cc | 25 +++++++++++++++++++++++++ > 8 files changed, 104 insertions(+) > > diff --git a/mysql-test/r/subselect.result b/mysql-test/r/subselect.result > index ba52fd9..27e8eaa 100644 > --- a/mysql-test/r/subselect.result > +++ b/mysql-test/r/subselect.result > @@ -7081,3 +7081,15 @@ sq > NULL > deallocate prepare stmt; > drop table t1,t2,t3,t4; > +# MDEV-7122 > +# Assertion `0' failed in subselect_hash_sj_engine::init > +# > +SET SESSION big_tables=1; Please unset the variable back at the end of this testcase. We don't want the rest of the test to run with non-standard settings. > +CREATE TABLE t1(a char(255) DEFAULT '', KEY(a(10))) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci; > +INSERT INTO t1 VALUES(0),(0),(0); > +SELECT * FROM t1 WHERE a IN(SELECT MIN(a) FROM t1); > +a > +0 > +0 > +0 > +DROP TABLE t1; > diff --git a/mysql-test/r/subselect_no_mat.result b/mysql-test/r/subselect_no_mat.result > index d8d5c4e..4727f9f 100644 > --- a/mysql-test/r/subselect_no_mat.result > +++ b/mysql-test/r/subselect_no_mat.result > @@ -7078,6 +7078,18 @@ sq > NULL > deallocate prepare stmt; > drop table t1,t2,t3,t4; > +# MDEV-7122 > +# Assertion `0' failed in subselect_hash_sj_engine::init > +# > +SET SESSION big_tables=1; > +CREATE TABLE t1(a char(255) DEFAULT '', KEY(a(10))) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci; > +INSERT INTO t1 VALUES(0),(0),(0); > +SELECT * FROM t1 WHERE a IN(SELECT MIN(a) FROM t1); > +a > +0 > +0 > +0 > +DROP TABLE t1; > set optimizer_switch=default; > select @@optimizer_switch like '%materialization=on%'; > @@optimizer_switch like '%materialization=on%' > diff --git a/mysql-test/r/subselect_no_opts.result b/mysql-test/r/subselect_no_opts.result > index 78908bc..7c542dd 100644 > --- a/mysql-test/r/subselect_no_opts.result > +++ b/mysql-test/r/subselect_no_opts.result > @@ -7076,4 +7076,16 @@ sq > NULL > deallocate prepare stmt; > drop table t1,t2,t3,t4; > +# MDEV-7122 > +# Assertion `0' failed in subselect_hash_sj_engine::init > +# > +SET SESSION big_tables=1; > +CREATE TABLE t1(a char(255) DEFAULT '', KEY(a(10))) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci; > +INSERT INTO t1 VALUES(0),(0),(0); > +SELECT * FROM t1 WHERE a IN(SELECT MIN(a) FROM t1); > +a > +0 > +0 > +0 > +DROP TABLE t1; > set @optimizer_switch_for_subselect_test=null; > diff --git a/mysql-test/r/subselect_no_scache.result b/mysql-test/r/subselect_no_scache.result > index d1de4b8..3b58b3c 100644 > --- a/mysql-test/r/subselect_no_scache.result > +++ b/mysql-test/r/subselect_no_scache.result > @@ -7087,6 +7087,18 @@ sq > NULL > deallocate prepare stmt; > drop table t1,t2,t3,t4; > +# MDEV-7122 > +# Assertion `0' failed in subselect_hash_sj_engine::init > +# > +SET SESSION big_tables=1; > +CREATE TABLE t1(a char(255) DEFAULT '', KEY(a(10))) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci; > +INSERT INTO t1 VALUES(0),(0),(0); > +SELECT * FROM t1 WHERE a IN(SELECT MIN(a) FROM t1); > +a > +0 > +0 > +0 > +DROP TABLE t1; > set optimizer_switch=default; > select @@optimizer_switch like '%subquery_cache=on%'; > @@optimizer_switch like '%subquery_cache=on%' > diff --git a/mysql-test/r/subselect_no_semijoin.result b/mysql-test/r/subselect_no_semijoin.result > index 524a5dd..9246ffb 100644 > --- a/mysql-test/r/subselect_no_semijoin.result > +++ b/mysql-test/r/subselect_no_semijoin.result > @@ -7076,5 +7076,17 @@ sq > NULL > deallocate prepare stmt; > drop table t1,t2,t3,t4; > +# MDEV-7122 > +# Assertion `0' failed in subselect_hash_sj_engine::init > +# > +SET SESSION big_tables=1; > +CREATE TABLE t1(a char(255) DEFAULT '', KEY(a(10))) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci; > +INSERT INTO t1 VALUES(0),(0),(0); > +SELECT * FROM t1 WHERE a IN(SELECT MIN(a) FROM t1); > +a > +0 > +0 > +0 > +DROP TABLE t1; > set @optimizer_switch_for_subselect_test=null; > set @join_cache_level_for_subselect_test=NULL; > diff --git a/mysql-test/t/subselect.test b/mysql-test/t/subselect.test > index 67eac0d..5ca21ea 100644 > --- a/mysql-test/t/subselect.test > +++ b/mysql-test/t/subselect.test > @@ -5964,3 +5964,12 @@ EXECUTE stmt; > > deallocate prepare stmt; > drop table t1,t2,t3,t4; > + > +--echo # MDEV-7122 > +--echo # Assertion `0' failed in subselect_hash_sj_engine::init > +--echo # > +SET SESSION big_tables=1; > +CREATE TABLE t1(a char(255) DEFAULT '', KEY(a(10))) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci; > +INSERT INTO t1 VALUES(0),(0),(0); > +SELECT * FROM t1 WHERE a IN(SELECT MIN(a) FROM t1); > +DROP TABLE t1; > diff --git a/sql/opt_subselect.cc b/sql/opt_subselect.cc > index 827290f..a39e04b 100644 > --- a/sql/opt_subselect.cc > +++ b/sql/opt_subselect.cc > @@ -830,12 +830,14 @@ bool subquery_types_allow_materialization(Item_in_subselect *in_subs) > in_subs->sjm_scan_allowed= FALSE; > > bool all_are_fields= TRUE; > + uint32 total_key_length = 0; > for (uint i= 0; i < elements; i++) > { > Item *outer= in_subs->left_expr->element_index(i); > Item *inner= it++; > all_are_fields &= (outer->real_item()->type() == Item::FIELD_ITEM && > inner->real_item()->type() == Item::FIELD_ITEM); > + total_key_length += inner->max_length; > if (outer->cmp_type() != inner->cmp_type()) > DBUG_RETURN(FALSE); > switch (outer->cmp_type()) { > @@ -866,6 +868,14 @@ bool subquery_types_allow_materialization(Item_in_subselect *in_subs) > } > } > > + /* > + Make sure that create_tmp_table will not fail due to too long keys. > + See MDEV-7122. This check is performed inside create_tmp_table also and > + we must do it so that we know the table has keys created. > + */ > + if (total_key_length > HA_MAX_KEY_LENGTH || elements > HA_MAX_KEY_SEG) > + DBUG_RETURN(FALSE); > + > in_subs->types_allow_materialization= TRUE; > in_subs->sjm_scan_allowed= all_are_fields; > DBUG_PRINT("info",("subquery_types_allow_materialization: ok, allowed")); > diff --git a/sql/sql_select.cc b/sql/sql_select.cc > index f43f506..218a4ce 100644 > --- a/sql/sql_select.cc > +++ b/sql/sql_select.cc > @@ -15307,6 +15307,13 @@ create_tmp_table(THD *thd, TMP_TABLE_PARAM *param, List<Item> &fields, > if (!table->file) > goto err; > > + /* > + Temporary table storage engines must allow keys of at least > + HA_MAX_KEY_LENGT and at least HA_MAX_KEY_SEG key parts. psergey: typo. ^^^^^^^^^^^ > + */ > + DBUG_ASSERT(table->file->max_key_length() >= HA_MAX_KEY_LENGTH && > + table->file->max_key_parts() >= HA_MAX_KEY_SEG); > + > if (!using_unique_constraint) > reclength+= group_null_items; // null flag is stored separately > > @@ -15940,6 +15947,12 @@ bool create_internal_tmp_table(TABLE *table, KEY *keyinfo, > goto err; > > bzero(seg, sizeof(*seg) * keyinfo->key_parts); > + /* > + Note that a simillar check is performed during typo ^^^^^^^^^ > + subquery_types_allow_materialization. See MDEV-7122 for more details as > + to why. Whenever this changes, it must be updated there as well, for > + all tmp_table engines. > + */ > if (keyinfo->key_length > table->file->max_key_length() || > keyinfo->key_parts > table->file->max_key_parts() || > share->uniques) > @@ -16126,6 +16139,12 @@ bool create_internal_tmp_table(TABLE *table, KEY *keyinfo, > goto err; > > bzero(seg, sizeof(*seg) * keyinfo->key_parts); > + /* > + Note that a simillar check is performed during typo ^^^^^^^^^ > + subquery_types_allow_materialization. See MDEV-7122 for more details as > + to why. Whenever this changes, it must be updated there as well, for > + all tmp_table engines. > + */ > if (keyinfo->key_length > table->file->max_key_length() || > keyinfo->key_parts > table->file->max_key_parts() || > share->uniques) > @@ -16286,6 +16305,12 @@ create_internal_tmp_table_from_heap2(THD *thd, TABLE *table, > if (!(new_table.file= get_new_handler(&share, &new_table.mem_root, > new_table.s->db_type()))) > DBUG_RETURN(1); // End of memory > + /* > + Temporary table storage engines must allow keys of at least > + HA_MAX_KEY_LENGTH and at least HA_MAX_KEY_SEG key parts. > + */ > + DBUG_ASSERT(new_table.file->max_key_length() >= HA_MAX_KEY_LENGTH && > + new_table.file->max_key_parts() >= HA_MAX_KEY_SEG); > > save_proc_info=thd->proc_info; > thd_proc_info(thd, proc_info); > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits -- BR Sergei -- Sergei Petrunia, Software Developer MariaDB Corporation | Skype: sergefp | Blog: http://s.petrunia.net/blog

1 0

[Maria-developers] MTR related community contribution
by Vicențiu Ciorbaru 07 Feb '16

07 Feb '16

Hi Vlad, I'm looking at the community pull request https://github.com/grooverdan/mariadb-server/commit/a9dfee63bad7393002621f9… I have a question regarding your commit: 2943d2b7e99b4221ef481890fc9a56ad569f3985 The contribution aims to remove the hard limit of 50 unique ids as it seems to cause problems for some use cases with a lot of proceeses. It does this by either leaving it at 50 or to be equal to the number of spawned processes. I'm thinking that even setting the limit of unique ids to num_processes might cause problems if there is another mtr running in parallel and both have > 50 processes. This is probably minor but why set this limit so low? Wouldn't a larger number (say 10k) be ok? Or why not generate a random number and lock a file with that number? (if the random number is invalid, generate a new one. On average it should finish quite quickly) Thanks, Vicentiu

3 2

[Maria-developers] Invalid code in server_audit.c
by Vicențiu Ciorbaru 06 Feb '16

06 Feb '16

Hi Alexei, While investigating community contributions from Daniel Black (MDEV-9433), I came across this comment: [image: danblack]Daniel Black <https://mariadb.atlassian.net/secure/ViewProfile.jspa?name=danblack> added a comment - 2016-01-20 02:54 [plugin/server_audit/server_audit.c:402]: (error) Invalid number of character '{' when these macros are defined: 'DBUG_VOID_RETURN=return;DBUG_RETURN(a)=return a;HAVE_PSI_INTERFACE'. [plugin/server_audit/server_audit.c:402]: (error) Invalid number of character '{' when these macros are defined: 'DBUG_VOID_RETURN=return;DBUG_RETURN(a)=return a;HAVE_PSI_INTERFACE;HUGETLB_USE_PROC_MEMINFO'. [plugin/server_audit/server_audit.c:402]: (error) Invalid number of character '{' when these macros are defined: 'DBUG_VOID_RETURN=return;DBUG_RETURN(a)=return a;HAVE_PSI_INTERFACE;USE_ALARM_THREAD'. Exists in 5.5 https://github.com/MariaDB/server/blob/5.5/plugin/server_audit/server_audit… Remove second {{ I've had a look at the code mentioned there and key_LOCK_bigbuffer does not exist anywhere else. Since we're not getting any compilation issues, it means we're not compiling that bit of code due to the defines. This indeed is so, as MYSQL_DYNAMIC_PLUGIN is defined for that file on the default cmake config which leads to FLOGGER being defined. I could not figure out a way to actually compile the code with defines such that that bit of code actually compiles. Either way it would not compile, due to the missing symbol. Do you think that we should just remove the line that mentions key_LOCK_bigbuffer? Also, since this is something we have not caught during testing, can we test for this compilation configuration somehow? Vicentiu

1 0

[Maria-developers] MariaDB JIRA is moving
by Rasmus Johansson 05 Feb '16

05 Feb '16

The MariaDB JIRA instance that currently is in use for project and issue tracking will change. The current instance is hosted in Atlassian's cloud and it has worked well, but we have hit the maximum user limit of 2000 users. It's fantastic to see how many of you actually report bugs and other issues in the MariaDB project! To hit that limit also means that we have to migrate over to a self-hosted instance of JIRA. Below are important details about that change. When will the switch happen: Sat 27th of Feb What is the impact for me as a user of MariaDB's JIRA: 1. URL change - The current instance is hosted in Atalassian's cloud and has the URL mariadb.atlassian.net. The new one will be found at jira.mariadb.org starting from 28th of Feb. 2. RSS feeds - If you have been using JIRA's RSS feeds, you'll need to set up them again since the URL is changing What will happen to old JIRA: The mariadb.atlassian.net JIRA instance will be put into read-only mode and a banner will be visible on each page telling the URL of the new MariaDB JIRA instance. It will remain this way for some time since it has been referenced quite heavily from other sites. source: https://mariadb.org/mariadb-jira-is-moving/ -- Rasmus Johansson, VP Engineering MariaDB | t: +358 50 499 9589 | Skype: ratzpo

1 0

[Maria-developers] MDEV-8691 Multiple test failures on mips and mipsel platforms, suites federated and rpl
by Alexander Barkov 02 Feb '16

02 Feb '16

Hi Jan, can you please have a look into: https://mariadb.atlassian.net/browse/MDEV-8691 Otto managed to get a stack trace from mips machine. It seems to crash inside InnoDB. Thanks. #3 <signal handler called> #4 0x000000fff6b48e80 in std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*) () from /usr/lib/mips64el-linux-gnuabi64/libstdc++.so.6 #5 0x00000001207cf878 in std::__cxx11::list<unsigned char*, std::allocator<unsigned char*> >::_M_insert (__x=<synthetic pointer>, __position=..., this=0x118) at /usr/include/c++/5/bits/stl_list.h:1755 #6 std::__cxx11::list<unsigned char*, std::allocator<unsigned char*> >::push_back (__x=<synthetic pointer>, this=0x118) at /usr/include/c++/5/bits/stl_list.h:1089 #7 recv_dblwr_t::add (this=0x118, page=0xffeb004000 "\377\060~$") at /«PKGBUILDDIR»/storage/xtradb/log/log0recv.cc:4077 #8 0x00000001208df7f8 in buf_dblwr_init_or_load_pages (file=<optimized out>, path=0xfff678b029 <srv_read_only_mode> "", load_corrupt_pages=<optimized out>) at /«PKGBUILDDIR»/storage/xtradb/buf/buf0dblwr.cc:457 #9 0x000000fff66e42bc in open_or_create_data_files (sum_of_new_sizes=<synthetic pointer>, max_flushed_lsn=0xffffa89a50, min_flushed_lsn=0xffffa89a48, create_new_db=<synthetic pointer>) at /«PKGBUILDDIR»/storage/innobase/srv/srv0start.cc:1033 #10 innobase_start_or_create_for_mysql () at /«PKGBUILDDIR»/storage/innobase/srv/srv0start.cc:2105 #11 0x000000fff65f0028 in innobase_init (p=<optimized out>) at /«PKGBUILDDIR»/storage/innobase/handler/ha_innodb.cc:3400 #12 0x00000001204a17bc in ha_initialize_handlerton (plugin=0xfff5cb49f0) at /«PKGBUILDDIR»/sql/handler.cc:501 #13 0x00000001202fcafc in plugin_initialize (tmp_root=0xffffa91c40, tmp_root@entry=0x0, plugin=plugin@entry=0xfff5cb49f0, argc=0x120fdf680 <remaining_argc>, argc@entry=0x6, argv=0xfff5c7cc58, argv@entry=0xfd8, options_only=<optimized out>) at /«PKGBUILDDIR»/sql/sql_plugin.cc:1379 #14 0x00000001202fd7b0 in plugin_init (argc=0x6, argv=0xfd8, flags=<optimized out>) at /«PKGBUILDDIR»/sql/sql_plugin.cc:1659 #15 0x00000001202347ec in init_server_components () at /«PKGBUILDDIR»/sql/mysqld.cc:4850 #16 0x000000012023b83c in mysqld_main (argc=255, argv=0xff00000000) at /«PKGBUILDDIR»/sql/mysqld.cc:5445 #17 0x000000012021cf18 in main (argc=<optimized out>, argv=<optimized out>) at /«PKGBUILDDIR»/sql/main.cc:25

2 2

Re: [Maria-developers] 9f2e2d8: [MDEV-7978] Update grammar for new syntax
by Sergei Golubchik 02 Feb '16

02 Feb '16

Hi, Vicentiu! On Jan 19, Vicentiu Ciorbaru wrote: > revision-id: 9f2e2d89917709f9223fe2d4b75dc86d0297b4c4 (mariadb-10.1.8-113-g9f2e2d8) > parent(s): 83e197aa6bd3a7eb81482795732bfbdb3b415deb > author: Vicențiu Ciorbaru > committer: Vicențiu Ciorbaru > timestamp: 2016-01-17 17:07:21 +0200 > message: > > [MDEV-7978] Update grammar for new syntax > > Extend the syntax accepted by the grammar to account for the new create user > and alter user syntax. a couple of comments: > diff --git a/sql/sql_yacc.yy b/sql/sql_yacc.yy > index 3eb6a99..c1f4249 100644 > --- a/sql/sql_yacc.yy > +++ b/sql/sql_yacc.yy > @@ -7279,6 +7280,11 @@ alter: > lex->sql_command= SQLCOM_ALTER_SERVER; > lex->server_options.reset($3); > } OPTIONS_SYM '(' server_options_list ')' { } > + | ALTER opt_if_exists USER clear_privileges user_list > + require_clause resource_options > + { please, add a comment that "ALTER USER foo;" is allowed for MySQL compatibility > + Lex->sql_command= SQLCOM_ALTER_USER; > + } > ; > > ev_alter_on_schedule_completion: > @@ -15734,6 +15724,37 @@ grant_option: > } > ; > > +resource_option_list: > + resource_option_list resource_option {} > + | resource_option {} > + ; > + > +resource_options: better rename it to opt_resource_options (and opt_grant_options below) for consistency. In sql_yacc.yy optional clauses often start with opt_ and one can immediately see that they're optional in, for example | ALTER opt_if_exists USER clear_privileges user_list opt_require_clause opt_resource_options > + /* empty */ {} > + | WITH resource_option_list > + ; > + > + > +grant_options: > + /* empty */ {} > + | WITH grant_option_list {} > + ; Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

[Maria-developers] MDEV-9415 Crash with ConnectSE + MySQL ODBC driver + INSERT
by Alexander Barkov 02 Feb '16

02 Feb '16

Hi Georg, Can you please have a look into: https://mariadb.atlassian.net/browse/MDEV-9415 ConnectSE crashes on INSERT statements inside the ODBC driver, while UPDATE, SELECT, DELETE work fine. Any ideas how to track down the problem? Thanks.

1 1

Re: [Maria-developers] [Commits] 5dd6eb4: MDEV-9117: Client Server capability negotiation for MariaDB specific functionality
by Sergei Golubchik 01 Feb '16

01 Feb '16

Hi, Sanja! On Jan 28, OleksandrByelkin wrote: > revision-id: 5dd6eb45c418f61c749a7884d7b3e13d62f3bfb9 (mariadb-10.1.8-113-g5dd6eb4) > parent(s): 14d79a5e99f9992cabb7489203989ccdaacadb78 > committer: Oleksandr Byelkin > timestamp: 2016-01-28 14:58:12 +0100 > message: > > MDEV-9117: Client Server capability negotiation for MariaDB specific functionality Just a couple of comments: > New capability flags space. > Removed old progress flag, added new one. > > diff --git a/client/mysql.cc b/client/mysql.cc > index 3e08c87..715eed8 100644 > --- a/client/mysql.cc > +++ b/client/mysql.cc > @@ -152,7 +152,7 @@ static ulong opt_max_allowed_packet, opt_net_buffer_length; > static uint verbose=0,opt_silent=0,opt_mysql_port=0, opt_local_infile=0; > static uint my_end_arg; > static char * opt_mysql_unix_port=0; > -static int connect_flag=CLIENT_INTERACTIVE; > +static ulong connect_flag=CLIENT_INTERACTIVE; ulong width is not portable, remember trubles we had with ulong sysvars? better use ulonglong for 64bit and uint for 32bit. > static my_bool opt_binary_mode= FALSE; > static int interrupted_query= 0; > static char *current_host,*current_db,*current_user=0,*opt_password=0, > diff --git a/libmysql/client_settings.h b/libmysql/client_settings.h > index b233614..2577870 100644 > --- a/libmysql/client_settings.h > +++ b/libmysql/client_settings.h > @@ -27,7 +27,7 @@ extern char * mysql_unix_port; > When adding capabilities here, consider if they should be also added to > the server's version. > */ > -#define CLIENT_CAPABILITIES (CLIENT_LONG_PASSWORD | \ > +#define CLIENT_CAPABILITIES (CLIENT_MYSQL | \ really? CLIENT_MYSQL? Is it because they aren't using Connector/C yet? > CLIENT_LONG_FLAG | \ > CLIENT_TRANSACTIONS | \ > CLIENT_PROTOCOL_41 | \ > diff --git a/sql/sql_acl.cc b/sql/sql_acl.cc > index 2bcd351..dcb12e6 100644 > --- a/sql/sql_acl.cc > +++ b/sql/sql_acl.cc > @@ -11730,18 +11731,27 @@ static ulong parse_client_handshake_packet(MPVIO_EXT *mpvio, > */ > DBUG_ASSERT(net->read_pos[pkt_len] == 0); > > - ulong client_capabilities= uint2korr(net->read_pos); > + ulonglong client_capabilities= uint2korr(net->read_pos); > + compile_time_assert(sizeof(client_capabilities) >= 8); > if (client_capabilities & CLIENT_PROTOCOL_41) > { > - if (pkt_len < 4) > + if (pkt_len < 32) > return packet_error; > client_capabilities|= ((ulong) uint2korr(net->read_pos+2)) << 16; > + if (!(client_capabilities & CLIENT_MYSQL)) > + { > + // it is client with mariadb extensions > + ulonglong ext_client_capabilities= > + (((ulonglong)uint4korr(net->read_pos + 28)) << 32); > + client_capabilities|= ext_client_capabilities; > + } As I wrote earlier, please add here else if (client_capabilities & CLIENT_PROGRESS_OBSOLETE) client_capabilities|= MARIADB_CLIENT_PROGRESS; > } > > /* Disable those bits which are not supported by the client. */ > + compile_time_assert(sizeof(thd->client_capabilities) >= 8); > thd->client_capabilities&= client_capabilities; > > - DBUG_PRINT("info", ("client capabilities: %lu", thd->client_capabilities)); > + DBUG_PRINT("info", ("client capabilities 1: %llu", thd->client_capabilities)); why " 1" ? > if (thd->client_capabilities & CLIENT_SSL) > { > unsigned long errptr __attribute__((unused)); Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

2 1