- developers - lists.mariadb.org

[Maria-developers] SHOW EXPLAIN: All concurrency problems should be gone, please test
by Sergei Petrunia 07 Jun '12

07 Jun '12

Hi Elena, I've pushed the fix for all known SHOW EXPLAIN problems. I think, another round of testing is needed. You can do it right away, or wait until I resolve the open "different query output" problems. BR Sergei -- Sergei Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

1 0

Re: [Maria-developers] Please review: [Commits] Rev 3535: Fix for bug lp:1006231 in file:///home/tsk/mprog/src/5.3/
by Sergei Petrunia 01 Jun '12

01 Jun '12

Hi Timour, As discussed on the phone call: - Let's add a separate MDEV item to add "the assert". - Ok to push tis patch. On Wed, May 30, 2012 at 07:12:33PM +0300, Timour Katchaounov wrote: > Sergey, > > Could you please review yet another bug fix for expensive subqueries > executed during optimiziation. > > Timour > > ------------------------------------------------------------ > revno: 3535 > revision-id: timour(a)askmonty.org-20120530161018-kgsiqesmnohtnbc6 > parent: holyfoot(a)askmonty.org-20120529045925-h35akgdit83ql5yq > fixes bug(s): https://launchpad.net/bugs/1006231 > committer: timour(a)askmonty.org > branch nick: 5.3 > timestamp: Wed 2012-05-30 19:10:18 +0300 > message: > Fix for bug lp:1006231 > > Analysis: > > When a subquery that needs a temp table is executed during > the prepare or optimize phase of the outer query, at the end > of the subquery execution all the JOIN_TABs of the subquery > are replaced by a new JOIN_TAB that selects from the temp table. > However that temp table has no corresponding TABLE_LIST. > Once EXPLAIN execution reaches its last phase, it tries to print > the names of the subquery tables through its TABLE_LISTs, but in > the case of this bug there is no such TABLE_LIST (it is NULL), > hence a crash. > > Solution: > The fix is to block subquery evaluation inside > Item_func_like::fix_fields and Item_func_like::select_optimize() > using the Item::is_expensive() test. > === modified file 'mysql-test/r/subselect_innodb.result' > --- a/mysql-test/r/subselect_innodb.result 2012-05-20 12:57:29 +0000 > +++ b/mysql-test/r/subselect_innodb.result 2012-05-30 16:10:18 +0000 > @@ -365,4 +365,19 @@ GROUP BY 1 > MAX( f1 ) > NULL > drop table t1, t2, t3; > +# > +# LP BUG#1006231 crash in select_describe > +# > +create table t1(a1 int) ENGINE=InnoDB; > +insert into t1 values (1); > +explain > +select 1 from t1 where 1 like (select 1 from t1 where 1 <=> (select 1 from t1 group by a1)); > +id select_type table type possible_keys key key_len ref rows Extra > +1 PRIMARY t1 ALL NULL NULL NULL NULL 1 > +2 SUBQUERY t1 ALL NULL NULL NULL NULL 1 > +3 SUBQUERY t1 ALL NULL NULL NULL NULL 1 Using temporary; Using filesort > +select 1 from t1 where 1 like (select 1 from t1 where 1 <=> (select 1 from t1 group by a1)); > +1 > +1 > +drop table t1; > set optimizer_switch=@subselect_innodb_tmp; > > === modified file 'mysql-test/t/subselect_innodb.test' > --- a/mysql-test/t/subselect_innodb.test 2012-05-20 12:57:29 +0000 > +++ b/mysql-test/t/subselect_innodb.test 2012-05-30 16:10:18 +0000 > @@ -356,4 +356,16 @@ WHERE f2 >= ( > > drop table t1, t2, t3; > > +--echo # > +--echo # LP BUG#1006231 crash in select_describe > +--echo # > + > +create table t1(a1 int) ENGINE=InnoDB; > +insert into t1 values (1); > +explain > +select 1 from t1 where 1 like (select 1 from t1 where 1 <=> (select 1 from t1 group by a1)); > +select 1 from t1 where 1 like (select 1 from t1 where 1 <=> (select 1 from t1 group by a1)); > +drop table t1; > + > + > set optimizer_switch=@subselect_innodb_tmp; > > === modified file 'sql/item_cmpfunc.cc' > --- a/sql/item_cmpfunc.cc 2012-05-20 12:57:29 +0000 > +++ b/sql/item_cmpfunc.cc 2012-05-30 16:10:18 +0000 > @@ -4656,7 +4656,7 @@ longlong Item_func_like::val_int() > > Item_func::optimize_type Item_func_like::select_optimize() const > { > - if (args[1]->const_item()) > + if (args[1]->const_item() && !args[1]->is_expensive()) > { > String* res2= args[1]->val_str((String *)&cmp.value2); > const char *ptr2; > @@ -4743,7 +4743,8 @@ bool Item_func_like::fix_fields(THD *thd > We could also do boyer-more for non-const items, but as we would have to > recompute the tables for each row it's not worth it. > */ > - if (args[1]->const_item() && !use_strnxfrm(collation.collation)) > + if (args[1]->const_item() && !use_strnxfrm(collation.collation) && > + !args[1]->is_expensive()) > { > String* res2 = args[1]->val_str(&cmp.value2); > if (!res2) > > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits -- BR Sergei -- Sergei Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

1 0

[Maria-developers] WL#252 New (by DonQuichote): IF (NOT) EXIST clauses for ALTER TABLE
by worklog-noreply＠askmonty.org 01 Jun '12

01 Jun '12

----------------------------------------------------------------------- WORKLOG TASK -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- TASK...........: IF (NOT) EXIST clauses for ALTER TABLE CREATION DATE..: Fri, 01 Jun 2012, 09:35 SUPERVISOR.....: IMPLEMENTOR....: COPIES TO......: CATEGORY.......: Server-RawIdeaBin TASK ID........: 252 (https://askmonty.org/worklog/?tid=252) VERSION........: WorkLog-4.0 STATUS.........: Un-Assigned PRIORITY.......: 60 WORKED HOURS...: 0 ESTIMATE.......: 0 (hours remain) ORIG. ESTIMATE.: 0 PROGRESS NOTES: DESCRIPTION: MySQL / MariaDB SQL is great as a functional language: you tell what you want and not how to do it. This includes suppressing of errors when the situation you want already exists. So there is a CREATE TABLE IF NOT EXISTS statement, for example (you say that you want the table to exist, not that it has to be built right now). It would be nice if altering a table could be done the same way: ALTER TABLE SomeTable ADD COLUMN IF NOT EXISTS SomeColumn ... ALTER TABLE SomeTable DROP COLUMN IF EXISTS SomeColumn ... ALTER TABLE SomeTable DROP FOREIGN KEY IF EXISTS SomeConstraint ... This would make definition scripts more legible and more friendly to existing databases. It would facilitate what I call "repeatable scripts", that can both create a new database and update an existing one to the latest structure. Mind you, this is already possible using temporary stored procedures (as shown in http://www.howtoforge.com/node/4833) but it would make definition scripts more maintainable and the SQL language more consistent. ESTIMATED WORK TIME ESTIMATED COMPLETION DATE ----------------------------------------------------------------------- WorkLog (v4.0.0)

1 0

Re: [Maria-developers] MariaDB 5.5.24 release prep
by Sergei Golubchik 31 May '12

31 May '12

Hi, Jocelyn! On May 31, Jocelyn Fournier wrote: > > Just to be sure : it means also the debian package will be properly > linked against libaio ? (it wasn't the case in 5.5.23 release). Unfortunately not. I mean that debian packages will be linked against libaio only in 5.5.25, but not in 5.5.24. Currently (in 5.5.24) only RPM packages are linked against libaio. Debian packages and bintar package are not. Regards, Sergei

1 0

Re: [Maria-developers] MariaDB 5.5.24 release prep
by Sergei Golubchik 31 May '12

31 May '12

Hi, md! On May 31, md wrote: > Sergei: > > I guess you can get 5.5.24 to build ok. I had a bunch of trouble with > 5.5.23 and a compiler error that I could not seem to make go away. > > [ 47%] Building CXX object > storage/oqgraph/CMakeFiles/oqgraph.dir/graphcore.cc.o > > In file included from > /usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:27:0, This is a known issue. An the OQGraph engine that we include is incompatible with the new Boost. It is a third-party engine, not ours. OQGraph developer knows about this problem and he's working on it. When he'll fix OQGraph, we will update it in our sources. Meanwhile we build without. Try to run cmake -DWITHOUT_OQGRAPH=1 in your build tree, and run make again. In 5.5.25 I'll make this the default behavior, until OQGraph is fixed. Regards, Sergei

1 0

Re: [Maria-developers] MariaDB 5.5.24 release prep
by Sergei Golubchik 31 May '12

31 May '12

Hi, Jocelyn! On May 31, Jocelyn Fournier wrote: > > Just wondering if the build issue with binaries and packages which don't > use native AIO is fixed as well ? > > (See https://bugs.launchpad.net/maria/+bug/988204 ) Doesn't seem so :( For some reason it was submitted in the wrong bugtracker, and I missed it when preparing a release. Sorry for this, it'll be in 5.5.25. This time - for sure. Note that 5.5 RPM packages are not affected by this bug - they are all properly linked with AIO. Regards, Sergei

1 0

[Maria-developers] MariaDB 5.5.24 release prep
by Daniel Bartholomew 31 May '12

31 May '12

All, I'm uploading the files for MariaDB 5.5.24 and getting other bits and pieces ready. Preliminary versions of the Release Notes and Changelog are available here: http://kb.askmonty.org/en/mariadb-5524-release-notes/ http://kb.askmonty.org/en/mariadb-5524-changelog/ The big news in this release is the new RPM packages and the YUM repositories. I'm still working on getting all the various bits set up, but it's all coming together and with any luck, I should be able to flip the switch and announce the release tomorrow morning (U.S. Eastern Time). In the mean time, if there is anything which should be mentioned in the Release Notes, please let me know ASAP or jump in and edit the Release Notes directly. Thanks! -- Daniel Bartholomew MariaDB - http://mariadb.org Monty Program - http://montyprogram.com AskMonty Knowledgebase - http://kb.askmonty.org

1 0

Re: [Maria-developers] Support of the extended syntax for ANALYZE
by Sergei Golubchik 26 May '12

26 May '12

Hi, Igor! On May 10, Igor Babaev wrote: > Serg, > > Here's the patch we talked about on IRC today. ... > +ANALYZE TABLE t1(COLUMN(), INDEX()); > +ANALYZE TABLE t1(COLUMN(c,e,b), INDEX(idx2,idx4)); > +ANALYZE TABLE t1(COLUMN(*), INDEX(*)); I see what you want to do. I think it'll be more SQL-like, if it'll be more verbose, for example ANALYZE TABLE t1 FOR COLUMNS (c,e,d) INDEXES (idx2, idx4); I would prefer to drop parentheses too, but then the grammar will become ambiguous :( And instead of double (*) it could simply be ANALYZE TABLE t1 FULL; or ALL; it'd be similar to CHECK TABLE t1 EXTENDED; REPAIR TABLE t1 QUICK; etc Alternatively, it could have an explicit "PERSISTENT" keyword: ANALYZE TABLE t1 PERSISTENT; -- meaning all columns and indexes ANALYZE TABLE t1 PERSISTENT FOR COLUMNS (c,e,d) INDEXES (idx2, idx4); That's probably the best one. Reasonably SQL-like. And the most common use case (analyze all) is short, it's clearly the main, default behavior. And the clause to specify columns and indexes extends the default syntax. Regards, Sergei

4 6

[Maria-developers] SHOW EXPLAIN and LOCK_thd_data
by Sergei Petrunia 26 May '12

26 May '12

Hi Sergei, I've got a problem with SHOW EXPLAIN and LOCK_thd_data. SHOW EXPLAIN was modeled after the KILL command: it's actions are: lock LOCK_thread_count; find the thread $target_thr we need explain for; lock $target_thr->LOCK_thread_count; unlock LOCK_thread_count; send SHOW EXPLAIN request to $target_thr. wait until request is executed (or discarded) unlock $target_thr->LOCK_thread_count; This scheme works, as long as the target thread doesn't select from information_schema tables. With queries over I_S tables, it breaks, because I_S table may try to acquire current_thd->LOCK_thread_count during execution. Below I provide a stacktrace of one such case, line numbers are from lp:~maria-captains/maria/5.5-show-explain. My first thought was to change LOCK_thread_count to be a read/write mutex, but I wanted to hear your opinion, too. (gdb) wher #0 inline_mysql_mutex_lock (that=0xa1111d4, src_file=0x894b75c "sql/sql_class.h", src_line=3020) at include/mysql/psi/mysql_thread.h:608 #1 0x081dda85 in THD::set_open_tables (this=0xa1104b0, open_tables_arg=0xa12de10) at sql/sql_class.h:3020 #2 0x081d9024 in open_table (thd=0xa1104b0, table_list=0xa1289b0, mem_root=0x99134000, ot_ctx=0x99134020) at sql/sql_base.cc:3180 #3 0x081d9aee in open_and_process_table (thd=0xa1104b0, lex=0x9913417c, tables=0xa1289b0, counter=0x991340bc, flags=1026, prelocking_strategy=0x991340c0, has_prelocking_list=false, ot_ctx=0x99134020, new_frm_mem=0x99134000) at sql/sql_base.cc:4509 #4 0x081da269 in open_tables (thd=0xa1104b0, start=0x991340d4, counter=0x991340bc, flags=1026, prelocking_strategy=0x991340c0) at sql/sql_base.cc:4958 #5 0x081da6de in open_normal_and_derived_tables (thd=0xa1104b0, tables=0xa1289b0, flags=1026, dt_phases=34) at sql/sql_base.cc:5617 #6 0x082a3e23 in fill_schema_table_by_open (thd=0xa1104b0, is_show_fields_or_keys=true, table=0xa1263c0, schema_table=0x8c262b0, orig_db_name=0x99134e04, orig_table_name=0x99134e1c, open_tables_state_backup=0x99134d94, can_deadlock=false) at sql/sql_show.cc:3659 #7 0x082b8638 in get_all_tables (thd=0xa1104b0, tables=0xa11d560, cond=0x0) at sql/sql_show.cc:4214 #8 0x0829f943 in do_fill_table (thd=0xa1104b0, table_list=0xa11d560, join_table=0xa128548) at sql/sql_show.cc:7503 #9 0x0829fce2 in get_schema_tables_result (join=0xa1279a8, executed_place=PROCESSED_BY_JOIN_EXEC) at sql/sql_show.cc:7610 #10 0x0829468d in JOIN::exec_inner (this=0xa1279a8) at sql/sql_select.cc:2354 #11 0x082931c8 in JOIN::exec (this=0xa1279a8) at sql/sql_select.cc:2201 BR Sergei -- Sergei Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

2 1

Re: [Maria-developers] Please review: [Commits] Rev 3405: Test case for bug lp:1001117, MySQL BUG#12330344 in file:///home/tsk/mprog/src/5.5-lpb944706/
by Sergei Petrunia 24 May '12

24 May '12

Hi Timour, On Thu, May 24, 2012 at 02:12:12PM +0300, Timour Katchaounov wrote: > Sergey, > > Could you please review the following patch. So far it is only in my > tree for bug lp:944706 (because this tree already fixes the problem as > explained below). > Ok to push. BR Sergei -- Sergei Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

1 0