- developers - lists.mariadb.org

[Maria-developers] Buildbot failure in 10.0-base
by Sergei Petrunia 23 Aug '13

23 Aug '13

Hi Kristian, 10.0-base started to get compile failures on [nearly] all hosts after your yesterday push: > 3682. By Kristian Nielsen 22 hours ago > MDEV-4488: When master is on the list of ignore_server_ids, GTID position on > slave is not updated > > The ignored events are not written to the relay log, but instead a fake > Rotate event is generated to handle update of position. > > Extend this for Gtid so we similarly generate a fake Gtid_list event > to update the GTID position. > > Also fix an unrelated test issue that got triggered by the added test cases. Could you please look into this? BR Sergei -- Sergei Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

2 1

[Maria-developers] MariaDB mutex contention (was: Re: MariaDB 10.0 benchmarks on upcoming IVB-EP processors ...)
by Axel Schwenke 22 Aug '13

22 Aug '13

Hi, Michael Widenius wrote: > 10.0.4 should be very soon ready for benchmarking (Tuesday or > Wednesday). We are in the final stage of fixing the failing test cases > after our last merge with MySQL 5.6 GA. > > I would just prefer to see Sergei Vojtovich push his code that changes > how the table cache works. > > This solves the same problem as the split table cache in 5.6, > but is a much simpler and better implementation. > > After this, I would expect that MariaDB 10.0 performance would be > closer to 5.6 performance for this benchmark. > Axel, could you at some point run the same benchmark with MariaDB > 10.0.4 and MySQL 5.6 with gprof to see where time is spent? I have now beefed up my knowledge of performance_schema and used it to look at Mutex/RW-lock contention for readonly OLTP benchmark. ----- TL;DR: 10.0.4 spends very long time in LOCK_PLUGIN, LOCK_OPEN is indeed much better than 10.0.3 but not(?) nearly as good as MySQL-5.6. ----- Contestants: - MySQL-5.6.13 (release) - MariaDB-10.0.3 (release) - MariaDB-10.0 r3799 (bzr trunk) all 3 compiled from source on benchmark machine using the same build script Environment: - many core machine (32 cores, 64 threads) - sysbench-0.5 OLTP readonly, 10M rows, single table - mysqld bound to 48 cores (sysbench to the other 8) - tested with 64 threads (this is the sweet spot) - using tcmalloc (preloaded) - mutexes and rw locks fully instrumented via performance_schema, see my.cnf Benchmark results (transactions per second): P_S on P_S off MySQL: ~15K ~18K 10.0.3: ~7K ~7.5K 10.0.4: ~6.5K ~9K After stabilizing I took 3 probes from P_S, sorting by sum_timer_wait desc. Times shown by P_S are picoseconds. If this were seconds, the decimal point would be in the column between "m" and "_" in "sum_timer_wait". So i.e. 10.0.4 waited 242 seconds for LOCK_PLUGIN during the 10 second measurement interval. Since we have 48 cores, there are total 480 seconds and 10.0.4 wasted about 50% of that. Questions: - what is protected by LOCK_PLUGIN? - how is LOCK_OPEN split in MySQL-5.6?If some of that is now covered by THR_LOCK::mutex, then it would explain why this is the busiest mutex in MySQL-5.6. Let me know if you need more data from me or if you have ideas what else I should test. XL Top 20 Mutexes/RW-locks MySQL-5.6.13 +---------------------------------------------+------------+-----------------+ | event_name | count_star | sum_timer_wait | +---------------------------------------------+------------+-----------------+ | wait/synch/mutex/mysys/THR_LOCK::mutex | 3397732 | 123367802416236 | | wait/synch/rwlock/innodb/btr_search_latch | 1632176 | 22207357475142 | | wait/synch/rwlock/sql/LOCK_grant | 1682983 | 1526912505972 | | wait/synch/mutex/sql/LOCK_table_cache | 3397786 | 1247140492941 | | wait/synch/mutex/sql/THD::LOCK_thd_data | 9219327 | 1076510130276 | | wait/synch/rwlock/innodb/hash_table_locks | 4086413 | 1026755227155 | | wait/synch/mutex/innodb/trx_sys_mutex | 364146 | 639270297372 | | wait/synch/mutex/innodb/os_mutex | 149491 | 630758755641 | | wait/synch/rwlock/innodb/index_tree_rw_lock | 1016436 | 344264365074 | | wait/synch/rwlock/sql/MDL_lock::rwlock | 242778 | 183463650006 | | wait/synch/mutex/sql/MDL_map::mutex | 121342 | 69121460394 | | wait/synch/mutex/mysys/BITMAP::mutex | 242667 | 54426177477 | | wait/synch/mutex/innodb/fil_system_mutex | 179586 | 20229032103 | | wait/synch/mutex/sql/LOCK_plugin | 121352 | 15004585617 | | wait/synch/mutex/innodb/trx_mutex | 121475 | 13105527141 | | wait/synch/mutex/innodb/lock_mutex | 121374 | 12627692868 | | wait/synch/mutex/innodb/buf_pool_mutex | 2240 | 228234006 | | wait/synch/mutex/innodb/log_sys_mutex | 540 | 119752122 | | wait/synch/mutex/innodb/flush_list_mutex | 704 | 86802870 | | wait/synch/mutex/innodb/buf_dblwr_mutex | 640 | 30728817 | +---------------------------------------------+------------+-----------------+ MariaDB-10.0.3 +------------------------------------------------+------------+-----------------+ | event_name | count_star | sum_timer_wait | +------------------------------------------------+------------+-----------------+ | wait/synch/mutex/sql/LOCK_open | 3334966 | 251668176449112 | | wait/synch/mutex/mysys/THR_LOCK::mutex | 2206782 | 2761461343332 | | wait/synch/mutex/sql/LOCK_plugin | 2540899 | 1471913471196 | | wait/synch/mutex/sql/THD::LOCK_thd_data | 6485120 | 770989733856 | | wait/synch/rwlock/innodb/hash table locks | 3315788 | 674878255920 | | wait/synch/rwlock/innodb/btr_search_latch | 1358771 | 540950632524 | | wait/synch/mutex/innodb/trx_sys_mutex | 380210 | 245662486416 | | wait/synch/rwlock/sql/MDL_lock::rwlock | 191698 | 125257499748 | | wait/synch/mutex/sql/TABLE_SHARE::LOCK_ha_data | 1067704 | 95258676492 | | wait/synch/mutex/mysys/THR_LOCK_lock | 157621 | 52329482172 | | wait/synch/mutex/mysys/BITMAP::mutex | 154870 | 49415303736 | | wait/synch/mutex/sql/MDL_map::mutex | 79173 | 41936664096 | | wait/synch/mutex/innodb/fil_system_mutex | 129610 | 40258209024 | | wait/synch/mutex/innodb/lock_mutex | 93667 | 26848457928 | | wait/synch/mutex/innodb/trx_mutex | 94131 | 11398946760 | | wait/synch/mutex/innodb/buf_pool_mutex | 12672 | 571983480 | | wait/synch/mutex/innodb/buf_dblwr_mutex | 9152 | 312365052 | | wait/synch/mutex/innodb/log_sys_mutex | 456 | 138632868 | | wait/synch/mutex/innodb/flush_list_mutex | 480 | 109226268 | | wait/synch/mutex/innodb/os_mutex | 350 | 71117100 | +------------------------------------------------+------------+-----------------+ MariaDB-10.0-r3799 +---------------------------------------------+------------+-----------------+ | event_name | count_star | sum_timer_wait | +---------------------------------------------+------------+-----------------+ | wait/synch/mutex/sql/LOCK_plugin | 4194896 | 242595666533160 | | wait/synch/mutex/sql/LOCK_open | 1835243 | 33790056812460 | | wait/synch/mutex/mysys/THR_LOCK::mutex | 1835221 | 3136249420092 | | wait/synch/rwlock/sql/LOCK_tdc | 911928 | 1088553356028 | | wait/synch/mutex/sql/THD::LOCK_thd_data | 5766813 | 695664363024 | | wait/synch/rwlock/innodb/hash table locks | 2144715 | 513517462020 | | wait/synch/rwlock/innodb/btr_search_latch | 915043 | 399309801912 | | wait/synch/rwlock/sql/MDL_lock::rwlock | 131171 | 176610102480 | | wait/synch/mutex/innodb/trx_sys_mutex | 196751 | 154609451460 | | wait/synch/rwlock/innodb/index_tree_rw_lock | 527543 | 137903039712 | | wait/synch/mutex/sql/MDL_map::mutex | 158268 | 95133455712 | | wait/synch/mutex/innodb/fil_system_mutex | 97493 | 27285605172 | | wait/synch/mutex/mysys/BITMAP::mutex | 131099 | 26589125196 | | wait/synch/mutex/mysys/THR_LOCK_lock | 131105 | 23952666708 | | wait/synch/mutex/innodb/lock_mutex | 65579 | 10355822676 | | wait/synch/mutex/innodb/trx_mutex | 65812 | 9790097724 | | wait/synch/mutex/innodb/buf_pool_mutex | 11550 | 644569236 | | wait/synch/rwlock/innodb/checkpoint_lock | 2 | 236298492 | | wait/synch/mutex/innodb/buf_dblwr_mutex | 3880 | 156907368 | | wait/synch/mutex/innodb/flush_list_mutex | 692 | 124740900 | +---------------------------------------------+------------+-----------------+ Comparison ---------- MariaDB-10.0-r3799 MariaDB-10.0.3 MySQL-5.6.13 +---------------------------------------------+------------+-----------------+------------+-----------------+------------+-----------------+ | event_name | count_star | sum_timer_wait | count_star | sum_timer_wait | count_star | sum_timer_wait | +---------------------------------------------+------------+-----------------+------------+-----------------+------------+-----------------+ | wait/synch/mutex/sql/LOCK_plugin | 4194896 | 242595666533160 | 2540899 | 1471913471196 | 121352 | 15004585617 | | wait/synch/mutex/sql/LOCK_open | 1835243 | 33790056812460 | 3334966 | 251668176449112 | | wait/synch/mutex/mysys/THR_LOCK::mutex | 1835221 | 3136249420092 | 2206782 | 2761461343332 | 3397732 | 123367802416236 | | wait/synch/rwlock/sql/LOCK_tdc | 911928 | 1088553356028 | | wait/synch/mutex/sql/THD::LOCK_thd_data | 5766813 | 695664363024 | 6485120 | 770989733856 | 9219327 | 1076510130276 | | wait/synch/rwlock/innodb/hash table locks | 2144715 | 513517462020 | 3315788 | 674878255920 | 4086413 | 1026755227155 | | wait/synch/rwlock/innodb/btr_search_latch | 915043 | 399309801912 | 1358771 | 540950632524 | 1632176 | 22207357475142 | | wait/synch/rwlock/sql/MDL_lock::rwlock | 131171 | 176610102480 | 191698 | 125257499748 | 242778 | 183463650006 | | wait/synch/mutex/innodb/trx_sys_mutex | 196751 | 154609451460 | 380210 | 245662486416 | 364146 | 639270297372 | | wait/synch/rwlock/innodb/index_tree_rw_lock | 527543 | 137903039712 | 1016436 | 344264365074 | | wait/synch/mutex/sql/MDL_map::mutex | 158268 | 95133455712 | 79173 | 41936664096 | 121342 | 69121460394 | | wait/synch/mutex/innodb/fil_system_mutex | 97493 | 27285605172 | 129610 | 40258209024 | 179586 | 20229032103 | | wait/synch/mutex/mysys/BITMAP::mutex | 131099 | 26589125196 | 154870 | 49415303736 | 242667 | 54426177477 | | wait/synch/mutex/mysys/THR_LOCK_lock | 131105 | 23952666708 | 157621 | 52329482172 | | wait/synch/mutex/innodb/lock_mutex | 65579 | 10355822676 | 93667 | 26848457928 | 121374 | 12627692868 | | wait/synch/mutex/innodb/trx_mutex | 65812 | 9790097724 | 94131 | 11398946760 | 121475 | 13105527141 | | wait/synch/mutex/innodb/buf_pool_mutex | 11550 | 644569236 | 12672 | 571983480 | 2240 | 228234006 | | wait/synch/rwlock/innodb/checkpoint_lock | 2 | 236298492 | | wait/synch/mutex/innodb/buf_dblwr_mutex | 3880 | 156907368 | 9152 | 312365052 | 640 | 30728817 | | wait/synch/mutex/innodb/flush_list_mutex | 692 | 124740900 | 480 | 109226268 | 704 | 86802870 | +---------------------------------------------+------------+-----------------+------------+-----------------+------------+-----------------+

7 18

[Maria-developers] Flashback Feature patch review
by Lixun Peng 22 Aug '13

22 Aug '13

Hi Monty, I patched my flashback feature to 10.0-base, and this is the diff file, please help me to review it. How to use this feature? I added several new arguments for mysqlbinlog: --flashback (-B), it will let mysqlbinlog working on FLASHBACK mode. --table (-T), it likes -d, but this argument is for table. --review, it will le mysqlbinlog print the SQL for reviewing. Reviewing feature will create a new "review" table to record the data that will be changed by FLASHBACK feature. If you aren't special the --review-dbname/tablename, "review" table will created on current DB, and the table name will be "__"+original_table_name. And for getting the original table struct, mysqlbinlog need to connect mysql, so --user/--host/--password is needed if necessary. --review-dbname, the DB that you want to store the review table. --review-tablename the TABLE that you want to store the changed data. Only if you set -T, this argument is useful. For example: I have a table "t" in database "test", CREATE TABLE `t` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `info` varchar(32) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=9043880 DEFAULT CHARSET=utf8; And I done this operation, root@localhost : (none) 14:52:50> reset master; root@localhost : (none) 14:53:02> use test root@localhost : test 14:53:08> delete from t limit 10; root@localhost : test 14:53:25> insert into t (info) select "你好"; root@localhost : test 14:54:01> update t set info ='hello你好' limit 5; We can compare the output with --flashback or not. #client/mysqlbinlog /data/mysqldata_10.0/binlog/mysql-bin.000001 -vv -d test -T t --start-datetime="2013-03-27 14:54:00" > /tmp/1.sql #client/mysqlbinlog /data/mysqldata_10.0/binlog/mysql-bin.000001 -vv -uroot -d test -T t --start-datetime="2013-03-27 14:54:00" -B --review > /tmp/2.sql How to implement Flashback: 1. mysqlbinlog tool can parse the binlog files and print them, so we can use the most of code in mysqlbinlog. 2. Changing the event type (INSERT -> DELETE, DELETE -> INSERT) 3. Exchanging the SET/WHERE part in UPDATE (UPDATE table SET x=1 WHERE y=2 -> UPDATE table SET y=2 WHERE x=1) 4. Invert the event output, from end to beginning (binlog: e1,e2,e3... -> flashback_log: en...e3,e2,e1) Then, importing the flashback output can flashback database/table to the special time. But binlog_format should be ROW. Thanks, Lixun -- Senior MySQL Developer @ Taobao.com Mobile Phone: +86 18658156856 (Hangzhou) Gtalk: penglixun(at)gmail.com Twitter: http://www.twitter.com/plinux Blog: http://www.penglixun.com

2 3

[Maria-developers] MariaDB config files order
by Honza Horak 20 Aug '13

20 Aug '13

Hi guys, maybe I just need some little kick or I should get a coffee, but I can't understand the following config file ordering difference. Reading [1] and code in mariadb-5.5.32/mysys/default.c:1226, it looks like expected order of config files in Linux should be: /etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf However, when asking for that using --help --verbose, I get a bit different output: $ /usr/libexec/mysqld --help --verbose 2>/dev/null | grep --after=1 '^Default options' | tail -n 2 Default options are read from the following files in the given order: /etc/mysql/my.cnf /etc/my.cnf ~/.my.cnf I don't understand why /etc/my.cnf is not on the first place in that output. Can somebody give me a hint? Am I just blind? Just FTR I'm trying that on Fedora 19, but there are no changes in Fedora packages that would do anything related, so I guess the same result would be in other distros as well. [1] https://kb.askmonty.org/en/mysqld-startup-options/ Cheers, Honza

2 3

Re: [Maria-developers] [Commits] Rev 3677: Fix bug MDEV-4895 Valgrind warnings (Conditional jump or move depends on uninitialised value) in Field_datetime::get_date on GREATEST(..) IS NULL in file:///home/tsk/mprog/src/5.3/
by Alexander Barkov 20 Aug '13

20 Aug '13

Hi Timour, The patch looks Okey to push for me. Please find two small neat-peaking comments below though :) On 08/20/2013 04:36 PM, timour(a)askmonty.org wrote: > At file:///home/tsk/mprog/src/5.3/ > > ------------------------------------------------------------ > revno: 3677 > revision-id: timour(a)askmonty.org-20130820123610-cjtgvaybl1ip3128 > parent: igor(a)askmonty.org-20130815235920-io2h7tlypwlbunsp > fixes bug: https://mariadb.atlassian.net/browse/MDEV-4895 > committer: timour(a)askmonty.org > branch nick: 5.3 > timestamp: Tue 2013-08-20 15:36:10 +0300 > message: > Fix bug MDEV-4895 Valgrind warnings (Conditional jump or move depends on uninitialised value) in Field_datetime::get_date on GREATEST(..) IS NULL > > Analysis: > The cause of the valgrind warning was an attempt to evaluate a Field that was not yet read. > The reason was that on one hand Item_func_isnotnull was marked as constant by > Item_func_isnotnull::update_used_tables, and this allowed eval_const_cond() to be called. > On the other hand Item_func_isnotnull::val_int() evaluated its argument as if it was not > constant. > > Solution: > The fix make sure that Item_func_isnotnull::val_int() doesn't evaluate its argument when > it is constant and cannot be NULL, because the result is known in this case. > > > > === modified file 'mysql-test/r/null.result' > --- a/mysql-test/r/null.result 2011-11-21 13:16:16 +0000 > +++ b/mysql-test/r/null.result 2013-08-20 12:36:10 +0000 > @@ -343,3 +343,33 @@ Field Type Null Key Default Extra > IFNULL(NULL, b) decimal(1,0) YES NULL > DROP TABLE t1, t2; > # End of 5.0 tests > +# > +# MDEV-4895 Valgrind warnings (Conditional jump or move depends on uninitialised value) in Field_datetime::get_date on GREATEST(..) IS NULL > +# > +CREATE TABLE t1 (dt DATETIME NOT NULL); > +INSERT INTO t1 VALUES (NOW()),(NOW()); > +EXPLAIN > +SELECT * FROM t1 WHERE concat( dt, '2012-12-21 12:12:12' ) IS NULL; > +id select_type table type possible_keys key key_len ref rows Extra > +1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Impossible WHERE > +SELECT * FROM t1 WHERE concat( dt, '2012-12-21 12:12:12' ) IS NULL; > +dt > +drop table t1; > +CREATE TABLE t1 (dt INT NOT NULL); > +INSERT INTO t1 VALUES (1),(2); > +EXPLAIN > +SELECT * FROM t1 WHERE concat( dt, '1' ) IS NULL; > +id select_type table type possible_keys key key_len ref rows Extra > +1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Impossible WHERE > +SELECT * FROM t1 WHERE concat( dt, '1' ) IS NULL; > +dt > +drop table t1; > +CREATE TABLE t1 (dt INT NOT NULL); > +INSERT INTO t1 VALUES (1),(2); > +EXPLAIN > +SELECT * FROM t1 WHERE NOT (concat( dt, '1' ) IS NOT NULL); > +id select_type table type possible_keys key key_len ref rows Extra > +1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Impossible WHERE > +SELECT * FROM t1 WHERE NOT (concat( dt, '1' ) IS NOT NULL); > +dt > +drop table t1; Please fix "drop table" to upper case here, and in the other places. > > === modified file 'mysql-test/t/null.test' > --- a/mysql-test/t/null.test 2009-02-10 03:00:11 +0000 > +++ b/mysql-test/t/null.test 2013-08-20 12:36:10 +0000 > @@ -255,3 +255,31 @@ DESCRIBE t2; > DROP TABLE t1, t2; > > --echo # End of 5.0 tests > + > +--echo # > +--echo # MDEV-4895 Valgrind warnings (Conditional jump or move depends on uninitialised value) in Field_datetime::get_date on GREATEST(..) IS NULL > +--echo # > + > +CREATE TABLE t1 (dt DATETIME NOT NULL); > +INSERT INTO t1 VALUES (NOW()),(NOW()); > + > +EXPLAIN > +SELECT * FROM t1 WHERE concat( dt, '2012-12-21 12:12:12' ) IS NULL; > +SELECT * FROM t1 WHERE concat( dt, '2012-12-21 12:12:12' ) IS NULL; > + > +drop table t1; > +CREATE TABLE t1 (dt INT NOT NULL); > +INSERT INTO t1 VALUES (1),(2); > +EXPLAIN > +SELECT * FROM t1 WHERE concat( dt, '1' ) IS NULL; > +SELECT * FROM t1 WHERE concat( dt, '1' ) IS NULL; > + > +drop table t1; > +CREATE TABLE t1 (dt INT NOT NULL); > +INSERT INTO t1 VALUES (1),(2); > + > +EXPLAIN > +SELECT * FROM t1 WHERE NOT (concat( dt, '1' ) IS NOT NULL); > +SELECT * FROM t1 WHERE NOT (concat( dt, '1' ) IS NOT NULL); > + > +drop table t1; > > === modified file 'sql/item_cmpfunc.cc' > --- a/sql/item_cmpfunc.cc 2013-08-15 23:59:20 +0000 > +++ b/sql/item_cmpfunc.cc 2013-08-20 12:36:10 +0000 > @@ -4621,6 +4621,8 @@ Item *and_expressions(Item *a, Item *b, > longlong Item_func_isnull::val_int() > { > DBUG_ASSERT(fixed == 1); > + if (const_item() && !args[0]->maybe_null) > + return false; "return 0" should be better in a longlong function. > return args[0]->is_null() ? 1: 0; > } > > @@ -4628,6 +4630,8 @@ longlong Item_is_not_null_test::val_int( > { > DBUG_ASSERT(fixed == 1); > DBUG_ENTER("Item_is_not_null_test::val_int"); > + if (const_item() && !args[0]->maybe_null) > + DBUG_RETURN(1); > if (args[0]->is_null()) > { > DBUG_PRINT("info", ("null")); >

1 0

Re: [Maria-developers] [Commits] MDEV-4923 file://home/jan/mysql/mariadb-5.5-mdev4923
by Sergei Golubchik 20 Aug '13

20 Aug '13

Hi, Jan! On Aug 20, Jan Lindström wrote: > Serg, > > Could you please review fix for MDEC-4923, where these changes are > pushed lp:maria/5.5 or lp:~maria-captains/maria/5.5 ? Looks correct. This seems to be XtraDB bug. lp:maria/5.5 is an alias for lp:~maria-captains/maria/5.5 > === modified file 'storage/xtradb/os/os0file.c' > --- storage/xtradb/os/os0file.c 2013-07-29 14:03:41 +0000 > +++ storage/xtradb/os/os0file.c 2013-08-20 05:35:22 +0000 > @@ -1658,8 +1658,8 @@ > } > } > > - if (srv_use_atomic_writes && type == OS_DATA_FILE && > - os_file_set_atomic_writes(file, name)) { > + if (srv_use_atomic_writes && type == OS_DATA_FILE && > + !os_file_set_atomic_writes(file, name)) { > CloseHandle(file); > *success = FALSE; > file = INVALID_HANDLE_VALUE; > @@ -1786,7 +1786,7 @@ > #endif /* USE_FILE_LOCK */ > > if (srv_use_atomic_writes && type == OS_DATA_FILE > - && os_file_set_atomic_writes(name, file)) { > + && !os_file_set_atomic_writes(name, file)) { > > *success = FALSE; > close(file); > Regards, Sergei

1 0

[Maria-developers] [Otto Kekäläinen] Fwd: initial feedback on mariadb
by Kristian Nielsen 20 Aug '13

20 Aug '13

Hi, Otto asked for help with the copyright file for the Debian MariaDB packages. As I understand it, the .deb packages have a file /usr/share/doc/mariadb-server-5.5/copyright and there are some scripts in Debian that check the file against what is in the headers of source files and possibly other checks (error output attached below). Otto did something, but there is apparently more needed. Can some of you who understand the finer points of licensing among Oracle, Monty Program, MariaDB Services, MariaDB foundation, Percona, ... please look into this and help Otto fix up things? Debian are usually very careful with licensing, so this could easily become a blocker otherwise (I assume). - Kristian.

4 4

[Maria-developers] MDEV-4911 - KILL command with query id
by Roberto Spadim 20 Aug '13

20 Aug '13

Hi guys, i sent some patchs, could anyone check it? it have some things to do: query syntax isn't in the MDEV-4911, i did a QUERY_ID instead of a more comlpex syntax (since i never used bison before :P ) the query_id works, but i need a new error message ( "Unknown query id: %") well i didn't make the gcc happy, there's some warnings, and i don't know if it's all right i send this patch after MDEV-4916 patch, in other words the %expect value of sql_yacc.yy is wrong if you don't apply the MDEV-4916 patch the 4916 is a IF_IDLE keyword to KILL command too it only kill if there's no query running well :) thanks guys! <https://mariadb.atlassian.net/browse/MDEV-4916> -- Roberto Spadim

2 3

Re: [Maria-developers] More Secure Kill Command
by Sergei Golubchik 20 Aug '13

20 Aug '13

Hi, Roberto! On Aug 17, Roberto Spadim wrote: > Hi sergei, > What about give two informations, thread id and query id > If thread id and query id is equal, kill it There's no need to. Query id identifies the query and the connection unambiguously. Specifying also a thread id is redundant. Regards, Sergei

2 9

[Maria-developers] linking an external library
by rg 19 Aug '13

19 Aug '13

Folks, I want to link an external library for a language extension. After several hours of trying to tell cmake (^%$@*&) to pick it up for linking the library would still not be built with. CMakeLists.txt in trunk/sql is in the meantime full of pointers to the library without avail. I did the normal FIND_LIBRARY() followed by TARGET_LINK_LIBRARIES({$LIBNAME}) on various targets plus as nothing worked: SET(CMAKE_LIBRARY_PATH) on it, explicity LINK_DIRECTORIES(), SET(CMAKE_PREFIX_PATH), SET(CMAKE_LIBRARY_PATH) ... How do I link mariadb with an external library?? Thanks Rob

3 4