- developers - lists.mariadb.org

Re: [Maria-developers] [Commits] d0064c6: MDEV-7635: Convert log_queries_not_using_indexes to ulong
by Daniel Black 13 Oct '16

13 Oct '16

So this is making log-queries-not-using-indexes to take on the same meaning as min_examined_row_limit for the case of no-index and both seam to apply? Is thd->get_examined_row_count() the right comparison value if the non-indexed table had much fewer rows examined? Note - https://mariadb.com/kb/en/mariadb/server-system-variables/#log_queries_not_… needs updating and needs to reference min_examined_row_limit as well. Are log_slow_admin_statements / log_slow_slave_statements going to be modified in the same way and min-examined-row-limit to be deprecated? Is giving log-queries-not-using-indexes a default value of 5000 (as suggested for min-examined-row limit) applicable here? On 14/10/16 10:09, Nirbhay Choubey wrote: > revision-id: d0064c6e94414cfd6bbfcf171b1efabababe1d2e (mariadb-10.2.1-55-gd0064c6) > parent(s): 0d70fd0f9b7b8480b6053ef2dfcb55d917de2bca > author: Nirbhay Choubey > committer: Nirbhay Choubey > timestamp: 2016-10-13 19:09:53 -0400 > message: > > MDEV-7635: Convert log_queries_not_using_indexes to ulong > > --- > mysql-test/r/mysqld--help.result | 7 ++++--- > mysql-test/r/show_check.result | 10 +++++----- > mysql-test/r/variables.result | 4 ++-- > .../r/log_queries_not_using_indexes_basic.result | 18 ++++++++++-------- > .../t/log_queries_not_using_indexes_basic.test | 14 +++++++------- > mysql-test/t/show_check.test | 4 ++-- > sql/mysqld.cc | 2 +- > sql/mysqld.h | 2 +- > sql/sql_parse.cc | 3 ++- > sql/sys_vars.cc | 9 +++++---- > 10 files changed, 39 insertions(+), 34 deletions(-) > > diff --git a/mysql-test/r/mysqld--help.result b/mysql-test/r/mysqld--help.result > index cb1399d..2a570f8 100644 > --- a/mysql-test/r/mysqld--help.result > +++ b/mysql-test/r/mysqld--help.result > @@ -365,9 +365,10 @@ The following options may be given as the first argument: > --log-isam[=name] Log all MyISAM changes to file. > --log-output=name How logs should be written. Any combination of: NONE, > FILE, TABLE > - --log-queries-not-using-indexes > + --log-queries-not-using-indexes[=#] > Log queries that are executed without benefit of any > - index to the slow log if it is open > + index and that examined fewer rows than specified to the > + slow log if it is open > --log-short-format Don't log extra information to update and slow-query > logs. > --log-slave-updates Tells the slave to log the updates from the slave thread > @@ -1257,7 +1258,7 @@ log-bin-trust-function-creators FALSE > log-error > log-isam myisam.log > log-output FILE > -log-queries-not-using-indexes FALSE > +log-queries-not-using-indexes 0 > log-short-format FALSE > log-slave-updates FALSE > log-slow-admin-statements FALSE > diff --git a/mysql-test/r/show_check.result b/mysql-test/r/show_check.result > index 19a2597..db1a0ee 100644 > --- a/mysql-test/r/show_check.result > +++ b/mysql-test/r/show_check.result > @@ -1228,27 +1228,27 @@ use test; > flush status; > show variables like "log_queries_not_using_indexes"; > Variable_name Value > -log_queries_not_using_indexes ON > +log_queries_not_using_indexes 1 > select 1 from information_schema.tables limit 1; > 1 > 1 > show status like 'slow_queries'; > Variable_name Value > Slow_queries 1 > -set global log_queries_not_using_indexes=OFF; > +set global log_queries_not_using_indexes=0; > show variables like "log_queries_not_using_indexes"; > Variable_name Value > -log_queries_not_using_indexes OFF > +log_queries_not_using_indexes 0 > select 1 from information_schema.tables limit 1; > 1 > 1 > show status like 'slow_queries'; > Variable_name Value > Slow_queries 1 > -set global log_queries_not_using_indexes=ON; > +set global log_queries_not_using_indexes=1; > show variables like "log_queries_not_using_indexes"; > Variable_name Value > -log_queries_not_using_indexes ON > +log_queries_not_using_indexes 1 > select 1 from information_schema.tables limit 1; > 1 > 1 > diff --git a/mysql-test/r/variables.result b/mysql-test/r/variables.result > index 50379a5..1423284 100644 > --- a/mysql-test/r/variables.result > +++ b/mysql-test/r/variables.result > @@ -995,10 +995,10 @@ select @@log_queries_not_using_indexes; > 0 > show variables like 'log_queries_not_using_indexes'; > Variable_name Value > -log_queries_not_using_indexes OFF > +log_queries_not_using_indexes 0 > select * from information_schema.session_variables where variable_name like 'log_queries_not_using_indexes'; > VARIABLE_NAME VARIABLE_VALUE > -LOG_QUERIES_NOT_USING_INDEXES OFF > +LOG_QUERIES_NOT_USING_INDEXES 0 > select @@""; > ERROR 42000: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '""' at line 1 > select @@&; > diff --git a/mysql-test/suite/sys_vars/r/log_queries_not_using_indexes_basic.result b/mysql-test/suite/sys_vars/r/log_queries_not_using_indexes_basic.result > index fcb5abb..9dafcb7 100644 > --- a/mysql-test/suite/sys_vars/r/log_queries_not_using_indexes_basic.result > +++ b/mysql-test/suite/sys_vars/r/log_queries_not_using_indexes_basic.result > @@ -29,10 +29,12 @@ SELECT @@global.log_queries_not_using_indexes; > @@global.log_queries_not_using_indexes > 0 > SET GLOBAL log_queries_not_using_indexes= ON; > +ERROR 42000: Incorrect argument type to variable 'log_queries_not_using_indexes' > SELECT @@global.log_queries_not_using_indexes; > @@global.log_queries_not_using_indexes > -1 > +0 > SET GLOBAL log_queries_not_using_indexes= OFF; > +ERROR 42000: Incorrect argument type to variable 'log_queries_not_using_indexes' > SELECT @@global.log_queries_not_using_indexes; > @@global.log_queries_not_using_indexes > 0 > @@ -47,20 +49,20 @@ SELECT @@global.log_queries_not_using_indexes; > @@global.log_queries_not_using_indexes > 0 > SET @@global.log_queries_not_using_indexes= 'DEFAULT'; > -ERROR 42000: Variable 'log_queries_not_using_indexes' can't be set to the value of 'DEFAULT' > +ERROR 42000: Incorrect argument type to variable 'log_queries_not_using_indexes' > SET @@global.log_queries_not_using_indexes= 'true'; > -ERROR 42000: Variable 'log_queries_not_using_indexes' can't be set to the value of 'true' > +ERROR 42000: Incorrect argument type to variable 'log_queries_not_using_indexes' > SET @@global.log_queries_not_using_indexes= BLABLA; > -ERROR 42000: Variable 'log_queries_not_using_indexes' can't be set to the value of 'BLABLA' > +ERROR 42000: Incorrect argument type to variable 'log_queries_not_using_indexes' > SET @@global.log_queries_not_using_indexes= 25; > -ERROR 42000: Variable 'log_queries_not_using_indexes' can't be set to the value of '25' > SET GLOBAL log_queries_not_using_indexes= -1; > -ERROR 42000: Variable 'log_queries_not_using_indexes' can't be set to the value of '-1' > +Warnings: > +Warning 1292 Truncated incorrect log_queries_not_using_indexes value: '-1' > SET @badvar= 'true'; > SET @@global.log_queries_not_using_indexes= @badvar; > -ERROR 42000: Variable 'log_queries_not_using_indexes' can't be set to the value of 'true' > +ERROR 42000: Incorrect argument type to variable 'log_queries_not_using_indexes' > SET GLOBAL log_queries_not_using_indexes= 'DEFAULT'; > -ERROR 42000: Variable 'log_queries_not_using_indexes' can't be set to the value of 'DEFAULT' > +ERROR 42000: Incorrect argument type to variable 'log_queries_not_using_indexes' > SET log_queries_not_using_indexes= TRUE; > ERROR HY000: Variable 'log_queries_not_using_indexes' is a GLOBAL variable and should be set with SET GLOBAL > SET SESSION log_queries_not_using_indexes= TRUE; > diff --git a/mysql-test/suite/sys_vars/t/log_queries_not_using_indexes_basic.test b/mysql-test/suite/sys_vars/t/log_queries_not_using_indexes_basic.test > index a726bff..806030d 100644 > --- a/mysql-test/suite/sys_vars/t/log_queries_not_using_indexes_basic.test > +++ b/mysql-test/suite/sys_vars/t/log_queries_not_using_indexes_basic.test > @@ -47,9 +47,11 @@ SELECT @@global.log_queries_not_using_indexes; > SET GLOBAL log_queries_not_using_indexes= DEFAULT; > SELECT @@global.log_queries_not_using_indexes; > > +--error ER_WRONG_TYPE_FOR_VAR > SET GLOBAL log_queries_not_using_indexes= ON; > SELECT @@global.log_queries_not_using_indexes; > > +--error ER_WRONG_TYPE_FOR_VAR > SET GLOBAL log_queries_not_using_indexes= OFF; > SELECT @@global.log_queries_not_using_indexes; > > @@ -66,26 +68,24 @@ SELECT @@global.log_queries_not_using_indexes; > # Check if the value in GLOBAL Table matches value in variable # > ################################################################# > > ---error ER_WRONG_VALUE_FOR_VAR > +--error ER_WRONG_TYPE_FOR_VAR > SET @@global.log_queries_not_using_indexes= 'DEFAULT'; > > ---error ER_WRONG_VALUE_FOR_VAR > +--error ER_WRONG_TYPE_FOR_VAR > SET @@global.log_queries_not_using_indexes= 'true'; > > ---error ER_WRONG_VALUE_FOR_VAR > +--error ER_WRONG_TYPE_FOR_VAR > SET @@global.log_queries_not_using_indexes= BLABLA; > > ---error ER_WRONG_VALUE_FOR_VAR > SET @@global.log_queries_not_using_indexes= 25; > > ---error ER_WRONG_VALUE_FOR_VAR > SET GLOBAL log_queries_not_using_indexes= -1; > > SET @badvar= 'true'; > ---error ER_WRONG_VALUE_FOR_VAR > +--error ER_WRONG_TYPE_FOR_VAR > SET @@global.log_queries_not_using_indexes= @badvar; > > ---error ER_WRONG_VALUE_FOR_VAR > +--error ER_WRONG_TYPE_FOR_VAR > SET GLOBAL log_queries_not_using_indexes= 'DEFAULT'; > > --error ER_GLOBAL_VARIABLE > diff --git a/mysql-test/t/show_check.test b/mysql-test/t/show_check.test > index a14c42d..9644b77 100644 > --- a/mysql-test/t/show_check.test > +++ b/mysql-test/t/show_check.test > @@ -945,11 +945,11 @@ flush status; > show variables like "log_queries_not_using_indexes"; > select 1 from information_schema.tables limit 1; > show status like 'slow_queries'; > -set global log_queries_not_using_indexes=OFF; > +set global log_queries_not_using_indexes=0; > show variables like "log_queries_not_using_indexes"; > select 1 from information_schema.tables limit 1; > show status like 'slow_queries'; > -set global log_queries_not_using_indexes=ON; > +set global log_queries_not_using_indexes=1; > show variables like "log_queries_not_using_indexes"; > select 1 from information_schema.tables limit 1; > show status like 'slow_queries'; > diff --git a/sql/mysqld.cc b/sql/mysqld.cc > index 28e91e2..f02f2b0 100644 > --- a/sql/mysqld.cc > +++ b/sql/mysqld.cc > @@ -395,7 +395,7 @@ my_bool disable_log_notes; > static my_bool opt_abort; > ulonglong log_output_options; > my_bool opt_userstat_running; > -my_bool opt_log_queries_not_using_indexes= 0; > +ulong opt_log_queries_not_using_indexes= 0; > bool opt_error_log= IF_WIN(1,0); > bool opt_disable_networking=0, opt_skip_show_db=0; > bool opt_skip_name_resolve=0; > diff --git a/sql/mysqld.h b/sql/mysqld.h > index 846a01a..d577a9b 100644 > --- a/sql/mysqld.h > +++ b/sql/mysqld.h > @@ -114,7 +114,7 @@ extern my_bool opt_backup_history_log; > extern my_bool opt_backup_progress_log; > extern ulonglong log_output_options; > extern ulong log_backup_output_options; > -extern my_bool opt_log_queries_not_using_indexes; > +extern ulong opt_log_queries_not_using_indexes; > extern bool opt_disable_networking, opt_skip_show_db; > extern bool opt_skip_name_resolve; > extern bool opt_ignore_builtin_innodb; > diff --git a/sql/sql_parse.cc b/sql/sql_parse.cc > index c76e22a..de2da9e 100644 > --- a/sql/sql_parse.cc > +++ b/sql/sql_parse.cc > @@ -2417,7 +2417,8 @@ void log_slow_statement(THD *thd) > if (((thd->server_status & SERVER_QUERY_WAS_SLOW) || > ((thd->server_status & > (SERVER_QUERY_NO_INDEX_USED | SERVER_QUERY_NO_GOOD_INDEX_USED)) && > - opt_log_queries_not_using_indexes && > + (opt_log_queries_not_using_indexes > 0) && > + (thd->get_examined_row_count() >= opt_log_queries_not_using_indexes) && > !(sql_command_flags[thd->lex->sql_command] & CF_STATUS_COMMAND))) && > thd->get_examined_row_count() >= thd->variables.min_examined_row_limit) > { > diff --git a/sql/sys_vars.cc b/sql/sys_vars.cc > index 47a0a38..d11d690 100644 > --- a/sql/sys_vars.cc > +++ b/sql/sys_vars.cc > @@ -1178,12 +1178,13 @@ static Sys_var_charptr Sys_log_error( > CMD_LINE(OPT_ARG, OPT_LOG_ERROR), > IN_FS_CHARSET, DEFAULT(disabled_my_option)); > > -static Sys_var_mybool Sys_log_queries_not_using_indexes( > +static Sys_var_ulong Sys_log_queries_not_using_indexes( > "log_queries_not_using_indexes", > - "Log queries that are executed without benefit of any index to the " > - "slow log if it is open", > + "Log queries that are executed without benefit of any index and that " > + "examined fewer rows than specified to the slow log if it is open", > GLOBAL_VAR(opt_log_queries_not_using_indexes), > - CMD_LINE(OPT_ARG), DEFAULT(FALSE)); > + CMD_LINE(OPT_ARG), VALID_RANGE(0, UINT_MAX), DEFAULT(0), > + BLOCK_SIZE(1)); > > static Sys_var_mybool Sys_log_slow_admin_statements( > "log_slow_admin_statements", > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits >

1 0

Re: [Maria-developers] [Commits] a3d469b: MDEV-11035: Restore removed disallow-writes for Galera
by Nirbhay Choubey 13 Oct '16

13 Oct '16

Hi Jan! On Wed, Oct 12, 2016 at 7:31 AM, Jan Lindström <jan.lindstrom(a)mariadb.com> wrote: > revision-id: a3d469b991732dddfafe966011e996166cd98671 > (mariadb-10.2.2-39-ga3d469b) > parent(s): 6e46de4a674c55858ec5b2528dcebb69010b34d6 > author: Jan Lindström > committer: Jan Lindström > timestamp: 2016-10-12 14:29:36 +0300 > message: > > MDEV-11035: Restore removed disallow-writes for Galera > > Found actually only one missing condition. > The patch is unfortunately incomplete. There are a bunch of WAIT_ALLOW_WRITES' (when compared to 10.1) that are currently missing in 10.2. Also, there is a memory leak as InnoDB does not free this event on shutdown (srv_free()). You can use galera.galera_var_innodb_disallow_writes to verify the fix. Best, Nirbhay > --- > storage/innobase/handler/ha_innodb.cc | 6 ++++-- > storage/innobase/srv/srv0srv.cc | 4 +--- > 2 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/storage/innobase/handler/ha_innodb.cc > b/storage/innobase/handler/ha_innodb.cc > index 1e74154..dc7e6eb 100644 > --- a/storage/innobase/handler/ha_innodb.cc > +++ b/storage/innobase/handler/ha_innodb.cc > @@ -23276,10 +23276,11 @@ innobase_disallow_writes_update( > { > *(my_bool*)var_ptr = *(my_bool*)save; > ut_a(srv_allow_writes_event); > - if (*(my_bool*)var_ptr) > + if (*(my_bool*)var_ptr) { > os_event_reset(srv_allow_writes_event); > - else > + } else { > os_event_set(srv_allow_writes_event); > + } > } > > static MYSQL_SYSVAR_BOOL(disallow_writes, innobase_disallow_writes, > @@ -23287,6 +23288,7 @@ static MYSQL_SYSVAR_BOOL(disallow_writes, > innobase_disallow_writes, > "Tell InnoDB to stop any writes to disk", > NULL, innobase_disallow_writes_update, FALSE); > #endif /* WITH_INNODB_DISALLOW_WRITES */ > + > static MYSQL_SYSVAR_BOOL(random_read_ahead, srv_random_read_ahead, > PLUGIN_VAR_NOCMDARG, > "Whether to use read ahead for random access within an extent.", > diff --git a/storage/innobase/srv/srv0srv.cc > b/storage/innobase/srv/srv0srv.cc > index 49de954..a46f62f 100644 > --- a/storage/innobase/srv/srv0srv.cc > +++ b/storage/innobase/srv/srv0srv.cc > @@ -1969,9 +1969,7 @@ DECLARE_THREAD(srv_error_monitor_thread)( > if (sync_array_print_long_waits(&waiter, &sema) > && sema == old_sema && os_thread_eq(waiter, old_waiter)) { > #if defined(WITH_WSREP) && defined(WITH_INNODB_DISALLOW_WRITES) > - if (true) { > - // JAN: TODO: MySQL 5.7 > - //if (srv_allow_writes_event->is_set) { > + if (os_event_is_set(srv_allow_writes_event)) { > #endif /* WITH_WSREP */ > fatal_cnt++; > #if defined(WITH_WSREP) && defined(WITH_INNODB_DISALLOW_WRITES) > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits

1 0

[Maria-developers] Error building mariadb-10.0 with Clang 3.8: Unqualified lookup in templates
by Luke Benes 13 Oct '16

13 Oct '16

Building mariadb-10.0 with Clang results in: graph_concepts.hpp:93:17: error: call to function 'out_edges' that is neither visible in the template definition nor found by argument-dependent lookup Full log: http://clang.debian.net/logs/2016-08-30/mariadb-10.0_10.0.26-3_unstable_cla…

2 1

Re: [Maria-developers] [MariaDB/server] Add new scheduling algorithm for reducing tail latencies (#245)
by Kristian Nielsen 12 Oct '16

12 Oct '16

Jiamin Huang <notifications(a)github.com> writes: > This branch introduces a new scheduling algorithm > (Variance-Aware-Transaction-Scheduling, VATS) for the record lock manager > of InnoDB and XtraDB. Instead of using First-Come-First-Served (FCFS), the > newly introduced algorithm uses an Eldest-Transaction-First (ETF) > heuristic, which prefers older transactions over new ones. It could be interesting to extend this to also understand commit order for in-order parallel replication. For in-order parallel replication, the commit order of transactions is fixed from the start. Suppose transactions Tm and Tn are both requesting the same record lock, and that Tm goes before Tn. If Tn gets the lock, it will be immediately killed since Tm must be allowed to go first. But there is no guarantee that Tm will be the older transaction. So prefering Tm over Tn here based on the commit order can potentially avoid some transaction rollback/retry. The function thd_deadlock_victim_preference() seems appropriate for overriding the age-of-transaction preference. If this function returns a prefered deadlock victim, give the lock to the other transaction. If not, the VATS algorithm can be applied. Especially in aggressive parallel replication, there can be a lot of conflicting transactions (one user reported 20% of transactions conflicting, while still getting good speedup from parallel replication). So it might be a worthwhile thing to do. - Kristian.

1 0

Re: [Maria-developers] Optimistic parallel replication for RocksDB
by Kristian Nielsen 11 Oct '16

11 Oct '16

Yoshinori Matsunobu <yoshinori(a)fb.com> writes: > About transaction ids, it's not visible from MyRocks yet. We're currently working on > RocksDB to add an API to get transaction id, and making it available via MyRocks. Ok, I see. Optimistic parallel replication needs the ability to somehow find the THD that is holding the row lock that is blocking another THD. If we have T1 followed by T2, T2 will only commit after T1 has. So if there is a conflicting row lock, we need a way to identify T2 so that the conflict can be resolved. Lock wait timeout is not sufficient here because of the requirement of in-order commit. > Rows are normally released at transaction commit or rollback, but there are some exceptions. > - Auto-increment id allocation is implemented as std::atomic<longlong> and > the lock is released earlier than statement/transaction, like > InnoDB. I hope this doesn't matter for > parallel replication, since auto-inc ids are always given on slaves > (either RBR image, or insert_id with SBR). Agree, it does not matter, MyRocks just should not report these lock conflicts with thd_rpl_deadlock_check() (and since this is using a different mechanism, there is no reason it would). > - MyRocks has data dictionary > (https://github.com/facebook/mysql-5.6/wiki/MyRocks-data-dictionary-format) > and data dictionary operations' transaction scope is different from > applications'. For example, internal index > id allocation is done (and committed) immediately. There is no SQL > statements to directly manipulate data dictionary, > so I assume this won't matter for replication either. Agree, it shouldn't. Optimistic parallel replication handles DDL pessimistically anyway - DDL is not run in parallel with any other statements. Thanks, - Kristian.

1 0

[Maria-developers] Optimistic parallel replication for RocksDB
by Kristian Nielsen 10 Oct '16

10 Oct '16

Sergey, Yoshinori, it was great talking to you about MyRocks in Amsterdam. I took a first look at how to extend MyRocks to work with optimistic parallel replication. It looks conceptually quite simple. Sergey, I understand you have more pressing priorities right now (like getting a tree to build :), so let us revisit this in more detail when you get to it. It looks like the fix is conceptually as simple as this patch, which calls thd_rpl_deadlock_check() whenever a transaction is blocked on a row lock: ----------------------------------------------------------------------- diff --git a/utilities/transactions/transaction_lock_mgr.cc b/utilities/transactions/transaction_lock_mgr.cc index 28e8598..5ff291f 100644 --- a/utilities/transactions/transaction_lock_mgr.cc +++ b/utilities/transactions/transaction_lock_mgr.cc @@ -317,6 +317,8 @@ Status TransactionLockMgr::AcquireWithTimeout(LockMap* lock_map, return result; } +extern "C" int thd_rpl_deadlock_check(MYSQL_THD thd, MYSQL_THD other_thd); + // Try to lock this key after we have acquired the mutex. // Sets *expire_time to the expiration time in microseconds // or 0 if no expiration. @@ -340,6 +342,9 @@ Status TransactionLockMgr::AcquireLocked(LockMap* lock_map, lock_info.expiration_time = txn_lock_info.expiration_time; // lock_cnt does not change } else { + THD *blocked_thd = getTHD(txn_lock_info.txn_id); + THD *bloking_thd = getTHD(lock_info.txn_id); + thd_rpl_deadlock_check(blocked_thd, blocking_thd); result = Status::TimedOut(Status::SubCode::kLockTimeout); } } ----------------------------------------------------------------------- A real patch will need some plumbing to put the code in the right place and have the right information available. Ie. probably the thd_rpl_deadlock_check() call will go into an overridden virtual method in ha_rocksdb.cc. I also did not check if/how one can get from txn_id to THD (what is called getTHD() above), I assume it can be implemented reasonably easy if it is not already there? Hints will be appreciated here as I am new to the MyRocks and RocksDB codebases. When are row locks released? I am interested in whether row locks can be released earlier than at transaction commit time. If so, the simple patch above will give false positives, and it might be worth it to investigate ways to not report locks that are released earlier than commit. Eg. in InnoDB, auto-increment locks are released earlier than commit, and thus are not reported. Once something like this is in place, I think optimistic parallel replication should work. In case of a conflict between transactions T1 and T2, thd_rpl_deadlock_check(T1, T2) will be called and will cause T2 to be killed so that T1 can proceed and T2 be re-tried afterwards. So things look good now; let us revisit this when there is a tree to work on. - Kristian.

1 0

Re: [Maria-developers] 8cd65cd: MDEV-9143 JSON_xxx functions.
by Sergei Golubchik 08 Oct '16

08 Oct '16

Hi, Alexey! On Oct 08, Alexey Botchkov wrote: > > Other comments, that you didn't reply to, does it mean you agree with > > them (like adding tests with values that need json-escaping)? Okay. > > Right, it means that I just agreed with the comment. > > I don't think we're going to need more unittest files so yep, will > move it to strings/ Will check for missing functions from MySQL, try > running MySQL tests with us, then push. > > After that we'll still have one inconsistency with MySQL - that they > have that JSON type for fields and values. JSON-values let the user > to compare values as 'json'-s. Not sure anybody ever uses it. But > JSON fields are probably good to import from MySQL, maybe in read-only > mode. Just to let people switch to MariaDB easily over these JSON > tables. Yes... I think, out of missing features, JSON_TABLE is the most interesting, but also the comlexity is a big unknown. The second one would be GeoJSON (and it's fairly predictable), then goes JSON comparison and JSON data type. Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

Re: [Maria-developers] 8cd65cd: MDEV-9143 JSON_xxx functions.
by Sergei Golubchik 08 Oct '16

08 Oct '16

Hi, Alexey! On Sep 21, Alexey Botchkov wrote: > > > > + In the worst case one character from the 'a' string > > > + turns into '\uXXXX\uXXXX' which is 12. > > > how comes? add an example, please. Like "for example, character x'1234' > > in the charset A becomes '\u1234\u5678' if JSON string is in the charset B" > > For instance the 'SMILING FACE WITH SUNGLASSES' character, > which is utf32(0001F60E) should be represented as \uD83D\uDE0E. I hope you put this in the comment in the code... Other comments, that you didn't reply to, does it mean you agree with them (like adding tests with values that need json-escaping)? Okay. Thanks for unit tests. There weren't many, but if you think they cover all the library functionality, then it's fine. Just one thought - do you expect any more json_lib related test *files* in the future? If not, you could move json_lib-t.cc into unittest/strings. And why the test is .cc? The file looked pure C to me. Anyway, I think it's ok to push after resolving these minor issues. Thanks! Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

Re: [Maria-developers] [Commits] 1c9da8d: MDEV-9312: storage engine not enforced during galera cluster replication
by Jan Lindström 29 Sep '16

29 Sep '16

Hi Nirbhay, This looks ok but one question (no need to change now): On Wed, Sep 28, 2016 at 7:36 PM, Nirbhay Choubey <nirbhay(a)mariadb.com> wrote: > > + Since some wsrep threads (THDs) are create before plugins are > + initialized, LOCK_plugin mutex needs to be initialized here. > + */ > Is there some fundamental reason why we can't create wsrep threads after other plugins and related global system variables (that are really needed for wsrep) are initialized ? R: Jan

2 1

Re: [Maria-developers] [Commits] a8162d4: MDEV-9312: storage engine not enforced during galera cluster replication
by Sergei Golubchik 28 Sep '16

28 Sep '16

Hi, Nirbhay! I don't understand, why do you need to create a dummy plugin here? On Sep 27, Nirbhay Choubey wrote: > revision-id: a8162d4a8737cff67889390fad0153acc175391d (mariadb-10.1.17-22-ga8162d4) > parent(s): 6a6b253a6ecbd4d3dd254044d12ec64475453275 > author: Nirbhay Choubey > committer: Nirbhay Choubey > timestamp: 2016-09-27 09:03:26 -0400 > message: > > MDEV-9312: storage engine not enforced during galera cluster replication > > Perform a post initialization of plugin-related variables > of wsrep threads after their global counterparts have been > initialized. ... > +#ifdef WITH_WSREP > + > +/* > + Placeholder for global_system_variables.table_plugin required during > + initialization of startup wsrep threads. > +*/ > +static st_plugin_int *wsrep_dummy_plugin; > + > +/* > + Initialize wsrep_dummy_plugin and assign it to > + global_system_variables.table_plugin. > +*/ > +void wsrep_plugins_pre_init() > +{ > + wsrep_dummy_plugin= > + (st_plugin_int *) my_malloc(sizeof(st_plugin_int), MYF(0)); > + wsrep_dummy_plugin->state= PLUGIN_IS_DISABLED; > + global_system_variables.table_plugin= plugin_int_to_ref(wsrep_dummy_plugin); > +} > + Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

2 2