April 2012 - developers - lists.mariadb.org

[Maria-developers] federated bug: Bug #61526 create table .. like .. federated table crashes with auto_increment column
by xiaobing jiang 14 May '12

14 May '12

hi all: I try to fix the bug: http://bugs.mysql.com/bug.php?id=61526. but after dig the code, I found that the federated seems don't support "create table xx like yy". the function miss the "share->connect_string", so it always report: ERROR 1 (HY000): server name: '' doesn't exist! from the page: http://kb.askmonty.org/en/about-federatedx, it says: The FederatedX Storage Engine is a fork of the Federated Storage Engine, the latter of the two no longer being maintained by Oracle. The purpose of FederatedX is to keep this storage engine's development progressing-- to both add new features as well as fix old bugs. is it really? so will oracle accept the patch? Thanks!

3 4

[Maria-developers] Request for testing: MWL#182 SHOW EXPLAIN
by Sergei Petrunia 11 May '12

11 May '12

Hi Elena, I need testing for MWL#182 SHOW EXPLAIN. The code is here: lp:~maria-captains/maria/5.3-show-explain2 (note the '2' at the end) The branch is currently based on 5.3, although will move to 5.5 soon (I suppose this doesn't cause any problems for testing). Currently, I can think of two things that need testing: === "Asynchronous Procedure Call" module === This is a module that allows one thread to schedule a call in the other thread, and wait until the call has been invoked. Suggested way to test: - run a set of queries that look at each other with "SHOW EXPLAIN FOR <thread>" statements. - have some "victim" threads which run long queries, and have "attacker" threads which submit a lot of "SHOW EXPLAIN FOR <victim_thread>" queries. === On-the-fly EXPLAIN printing functionality === Before this WL, the code that produced EXPLAIN output - Required that optimizer produces a slightly different structures when EXPLAIN is running - Did destructive modifications to the query plan (that is, it was not possible to call these functions two times to get two EXPLAIN outputs for the same planned query) Suggested way to test: - Run various complicated queries, with UNIONs, JOINs, etc. - While they are running, do SHOW EXPLAIN FOR command for them, expecting it to crash or produce nonsensical output at some point. If SHOW EXPLAIN crashes, the crash report will show the query it was trying to obtain the EXPLAIN for. My current suggestion is to use some "runner" threads to run the queries and use another set of threads to hit the "runner" threads with SHOW EXPLAIN request. When creating tests in mysql-test/t/show_explain.test, I made a framework that allows to stop query execution at some particular point and then wait until some number of SHOW EXPLAIN requests were arrived and served. This requires insertion of "probes" into the source code, though. Perhaps, we could use something like that for your testing: to have the query pause at some "interesting" points and wait for SHOW EXPLAIN requests to arrive and be served. I wasn't able to come up with any intelligent way to find interesting point though, so this is still just an idea. BR Sergei -- Sergei Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

1 1

[Maria-developers] KB Question: Ubuntu 10.04 LTS Server and MariaDB 5.5.23
by Daniel Bartholomew 07 May '12

07 May '12

A question has been posted to the Knowledgebase: http://kb.askmonty.org/en/ubuntu-1004-lts-server-and-mariadb-5523 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Ubuntu 10.04 LTS Server and MariaDB 5.5.23 After installing fresh mariadb, I'm having troubles using some software compiled with the mysql support. For ex. mysql2 ruby gem: Incorrect MySQL client library version! This gem was compiled for 5.5.23-MariaDB but the client library is 5.1.61 Quick investigation took me into this conclusions: mariadb-client-5.5 introduces new libmariadbclient18, but depends on libdbd-mysql-perl which depends on libmysqlclient16. So after install we have 2 libraries: libmysqlclient.so.16(from original mysql) and libmysqlclient.so.18(from mariadb). And default libmysqlclient.so is symlinked to libmysqlclient.so.16 Can this be solved in some way? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- Daniel Bartholomew MariaDB - http://mariadb.org Monty Program - http://montyprogram.com AskMonty Knowledgebase - http://kb.askmonty.org

2 1

[Maria-developers] KB Question: Aria features ?
by Daniel Bartholomew 30 Apr '12

30 Apr '12

A question has been posted to the Knowledgebase: http://kb.askmonty.org/en/aria-features - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Aria features ? When Aria Engine is a new generation MyISAM Engine , whether the new features: - parallel index creating? - merge table? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Thanks. -- Daniel Bartholomew MariaDB - http://mariadb.org Monty Program - http://montyprogram.com AskMonty Knowledgebase - http://kb.askmonty.org

1 0

[Maria-developers] KB question: parallel index creating
by Daniel Bartholomew 30 Apr '12

30 Apr '12

A question has been posted to the Knowledgebase: http://kb.askmonty.org/en/parallel-index-creating - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - parallel index creating? Hi all can we expect the creation of parallel index creating in MyISAM engine? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Thanks. -- Daniel Bartholomew MariaDB - http://mariadb.org Monty Program - http://montyprogram.com AskMonty Knowledgebase - http://kb.askmonty.org

1 0

Re: [Maria-developers] Request for testing: MWL#182 SHOW EXPLAIN
by Sergei Petrunia 27 Apr '12

27 Apr '12

On Fri, Apr 27, 2012 at 01:31:08PM +0400, Elena Stepanova wrote: > Hi Sergey, > > OK, I will start working on this. > > > Before this WL, the code that produced EXPLAIN output > > - Required that optimizer produces a slightly different structures > > when EXPLAIN is running > > - Did destructive modifications to the query plan > > Does this mean that the traditional EXPLAIN (preceding a statement or > subsequent to it) is also affected? > Yes. I've changed regular EXPLAIN code so that it can be ran multiple times. That way, traditional EXPLAIN is affected. There is one known difference, currently only documented in this e-mail (will forward it): Date: Sat, 27 Aug 2011 10:14:13 +0400 From: Sergey Petrunya <psergey(a)askmonty.org> To: maria-developers(a)lists.launchpad.net Subject: [Maria-developers] MWL#182: a problem select_type column, SIMPLE vs PRIMARY > By the way, s there any standard way of naming the new EXPLAIN, as > opposed to the old EXPLAIN? (e.g. Online EXPLAIN? Asynchronous? Running? > Parallel?) > This is just to simplify further talks. We call it "SHOW EXPLAIN", following the SQL syntax. Nobody has made an explicit decision on the "official" way to name it, but it looks like this name will stick. > Regards, > /E > > > On 4/27/2012 9:13 AM, Sergei Petrunia wrote: >> Hi Elena, >> >> I need testing for MWL#182 SHOW EXPLAIN. >> >> The code is here: lp:~maria-captains/maria/5.3-show-explain2 (note the '2' at >> the end) >> >> The branch is currently based on 5.3, although will move to 5.5 soon (I suppose >> this doesn't cause any problems for testing). >> >> Currently, I can think of two things that need testing: >> >> === "Asynchronous Procedure Call" module === >> This is a module that allows one thread to schedule a call in the other thread, >> and wait until the call has been invoked. >> >> Suggested way to test: >> - run a set of queries that look at each other with "SHOW EXPLAIN FOR<thread>" >> statements. >> - have some "victim" threads which run long queries, and have "attacker" >> threads which submit a lot of "SHOW EXPLAIN FOR<victim_thread>" queries. >> >> === On-the-fly EXPLAIN printing functionality === >> Before this WL, the code that produced EXPLAIN output >> - Required that optimizer produces a slightly different structures when EXPLAIN >> is running >> - Did destructive modifications to the query plan (that is, it was not possible >> to call these functions two times to get two EXPLAIN outputs for the same >> planned query) >> >> Suggested way to test: >> - Run various complicated queries, with UNIONs, JOINs, etc. >> - While they are running, do SHOW EXPLAIN FOR command for them, expecting >> it to crash or produce nonsensical output at some point. >> If SHOW EXPLAIN crashes, the crash report will show the query it was trying >> to obtain the EXPLAIN for. >> >> My current suggestion is to use some "runner" threads to run the queries and >> use another set of threads to hit the "runner" threads with SHOW EXPLAIN >> request. >> >> When creating tests in mysql-test/t/show_explain.test, I made a framework that >> allows to stop query execution at some particular point and then wait until >> some number of SHOW EXPLAIN requests were arrived and served. >> >> This requires insertion of "probes" into the source code, though. >> >> Perhaps, we could use something like that for your testing: to have the query >> pause at some "interesting" points and wait for SHOW EXPLAIN requests to arrive >> and be served. I wasn't able to come up with any intelligent way to find >> interesting point though, so this is still just an idea. >> >> BR >> Sergei -- BR Sergei -- Sergei Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

1 0

Re: [Maria-developers] [Bug 988694] Re: Client software depends on server PAM plugin setup
by sergii＠pisem.net 27 Apr '12

27 Apr '12

Hi, Predrag! On Apr 27, Predrag Zecevic wrote: > @Sergei, > > is that MariaDB PAM plugin portable to MySQL? > > Regards. > > BTW, thanks for clarifications about PAM plugin usage for MySQL. I'm taking this out of percona-pam-plugin bug report, hope it's ok. Personally, I didn't try it with MySQL. But because pluggable authentication in MySQL is pretty much the same as in MariaDB (in fact, we've implemented it, and contributed to Oracle), our pam plugin should work. It might need minor cosmetic changes to compile though. Alternatively, you can simply use MariaDB :) it has everything that MySQL does, plus much faster subqueries, much faster replication, and tons of other goodies. Regards, Sergei

2 1

[Maria-developers] lp:maria -> 5.3 or 5.5?
by Sergei Golubchik 27 Apr '12

27 Apr '12

Hi, Currently lp:maria is the same as lp:maria/5.3 - our main 5.3 branch. Typically for projects on launchpad, the short url points to a trunk. In our case it's an old (not even the latest) GA branch. I suggest to move lp:maria to be lp:maria/5.5 at once. And change to lp:maria/trunk as soon as we'll have it. Objections? Regards, Sergei

2 1

Re: [Maria-developers] bsd9 buildbot host
by Kristian Nielsen 27 Apr '12

27 Apr '12

Daniel Bartholomew <dbart(a)montyprogram.com> writes: > I've installed buildbot on the bsd9 host at Timour's office and set it > up as a buildslave. > However, the builder keeps throwing an exception right at the start of > the compile step. For example build 4: > http://buildbot.askmonty.org/buildbot/builders/bsd9-64/builds/4 > > The err.html file says: "exceptions.KeyError: 'keepstamp'" and the > err.text file says: "Traceback from remote host -- Traceback > unavailable". Looks like this is this bug: http://trac.buildbot.net/ticket/1995 Apparently this happens when Buildbot master tries to download the compiler warning suppression file from the slave. The `keepstamp' argument is mandatory for such download on the version of buildslave installed on that host due to above bug (IIUC). The easiest fix is probably just to disable the download of the suppression file. I think we can live without it. I tried that, and it seems to work - compile is running now. - Kristian.

1 0

[Maria-developers] MariaDB & InnoDB native aio disabled
by jocelyn fournier 25 Apr '12

25 Apr '12

Hi, I've just figured out after installing MariaDB 5.5.23 on two server (one directly from the x64 binary, and the other using the debian packing) that innodb_use_native_aio is OFF on the two servers. Before upgrading to MariaDB, I was using percona 5.5.21-rel25.1-234.squeeze, and innodb_use_native_aio was properly used. There's nothing wrong reported in the MySQL log. The log with percona 5.5.21 : 120425 3:55:46 InnoDB: The InnoDB memory heap is disabled 120425 3:55:46 InnoDB: Mutexes and rw_locks use GCC atomic builtins 120425 3:55:46 InnoDB: Compressed tables use zlib 1.2.3 120425 3:55:46 InnoDB: Using Linux native AIO 120425 3:55:46 InnoDB: Initializing buffer pool, size = 9.0G 120425 3:55:47 InnoDB: Completed initialization of buffer pool 120425 3:55:47 InnoDB: highest supported file format is Barracuda. 120425 3:55:50 InnoDB: Waiting for the background threads to start 120425 3:55:51 Percona XtraDB (http://www.percona.com) 1.1.8-rel25.1 started; log sequence number 33812567651 The log with mariadb 5.5.23 : 120425 3:41:04 InnoDB: The InnoDB memory heap is disabled 120425 3:41:04 InnoDB: Mutexes and rw_locks use GCC atomic builtins 120425 3:41:04 InnoDB: Compressed tables use zlib 1.2.3.4 120425 3:41:04 InnoDB: Initializing buffer pool, size = 9.0G 120425 3:41:04 InnoDB: Completed initialization of buffer pool 120425 3:41:04 InnoDB: highest supported file format is Barracuda. 120425 3:41:08 InnoDB: Waiting for the background threads to start 120425 3:41:09 Percona XtraDB (http://www.percona.com) 1.1.8-24.1 started; log sequence number 33812411088 (no more line saying Linux native AIO is used) Am I missing something ? Thanks and regards, Jocelyn Fournier -- This message was sent from Launchpad by jocelyn fournier (https://launchpad.net/~joce) to each member of the Maria Discuss team using the "Contact this team" link on the Maria Discuss team page (https://launchpad.net/~maria-discuss) For more information see https://help.launchpad.net/YourAccount/ContactingPeople

1 0

Re: [Maria-developers] [Commits] Rev 3365: Dependency of tests from ulong size removed. in file:///home/bell/maria/bzr/work-maria-5.5-MDEV-219-1/
by Sergei Golubchik 19 Apr '12

19 Apr '12

Hi, Sanja! On Apr 19, sanja(a)montyprogram.com wrote: > At file:///home/bell/maria/bzr/work-maria-5.5-MDEV-219-1/ > > ------------------------------------------------------------ > revno: 3365 > revision-id: sanja(a)montyprogram.com-20120419130044-inzqd6nnksyhcpa1 > parent: sergii(a)pisem.net-20120405135727-1kxtscd76rq6xw5o > committer: sanja(a)montyprogram.com > branch nick: work-maria-5.5-MDEV-219-1 > timestamp: Thu 2012-04-19 16:00:44 +0300 > message: > Dependency of tests from ulong size removed. Looks ok to me. But, please, don't push it directly to 5.5, run it in Buildbot on a stage tree first. If that'll show up all green - please push into 5.5. Regards, Sergei

1 0

[Maria-developers] WL#251 New (by Igor): Encapsulate calculations of the table access cost and make them consistent and tunable
by worklog-noreply＠askmonty.org 16 Apr '12

16 Apr '12

----------------------------------------------------------------------- WORKLOG TASK -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- TASK...........: Encapsulate calculations of the table access cost and make them consistent and tunable CREATION DATE..: Mon, 16 Apr 2012, 18:32 SUPERVISOR.....: IMPLEMENTOR....: COPIES TO......: Igor Knielsen Monty Psergey Sanja Sergei Timour Wlad CATEGORY.......: Server-Sprint TASK ID........: 251 (http://askmonty.org/worklog/?tid=251) VERSION........: Benchmarks-3.0 STATUS.........: Assigned PRIORITY.......: 60 WORKED HOURS...: 0 ESTIMATE.......: 0 (hours remain) ORIG. ESTIMATE.: 0 PROGRESS NOTES: DESCRIPTION: This task is mostly a re-engineering task. Currently when calculating the cost of a ref table access method the function best_access_path makes an assumption that any index look-up is performed into a B-tree and the function uses engine independent code for this calculations. The cost calculations also use some constants that should be done tunable through system variables since these constants may be different for different platform/environments. This task is implemented in preparation for the development that will support more realistic cost model for query execution plans. ESTIMATED WORK TIME ESTIMATED COMPLETION DATE ----------------------------------------------------------------------- WorkLog (v4.0.0)

1 0

Re: [Maria-developers] 3365: removed dependency of tests from ulong size
by Sergei Golubchik 12 Apr '12

12 Apr '12

Hi, Sanja! On Apr 12, sanja(a)montyprogram.com wrote: > At file:///home/bell/maria/bzr/work-maria-5.5-MDEV-219-1/ > > ------------------------------------------------------------ > revno: 3365 > revision-id: sanja(a)montyprogram.com-20120412051920-972kyz35kujeljyw > parent: sergii(a)pisem.net-20120405135727-1kxtscd76rq6xw5o > committer: sanja(a)montyprogram.com > branch nick: work-maria-5.5-MDEV-219-1 > timestamp: Thu 2012-04-12 08:19:20 +0300 > message: > removed dependency of tests from ulong size > > === modified file 'sql/sql_cache.cc' > --- a/sql/sql_cache.cc 2012-03-27 23:04:46 +0000 > +++ b/sql/sql_cache.cc 2012-04-12 05:19:20 +0000 > @@ -1348,9 +1348,15 @@ ulong Query_cache::resize(ulong query_ca > > ulong Query_cache::set_min_res_unit(ulong size) > { > - if (size < min_allocation_unit) > - size= min_allocation_unit; > - return (min_result_data_size= ALIGN_SIZE(size)); > + if (size > 0xFFFFFFF8) > + size= 0xFFFFFFF8; /* assign maximum 32bit aligned to avoid overflow */ why wouldn't you change size to be uint or ulonglong? > + else > + { > + if (size < min_allocation_unit) > + size= min_allocation_unit; > + size= ALIGN_SIZE(size); > + } > + return (min_result_data_size= size); > } Regards, Sergei

1 0

[Maria-developers] MariaDB 5.5.23-stable (GA) release
by Daniel Bartholomew 11 Apr '12

11 Apr '12

All, The 5.5.23 release notes and changelog are at: * http://kb.askmonty.org/en/mariadb-5523-release-notes * http://kb.askmonty.org/en/mariadb-5523-changelog Please let me know ASAP of any errors or omissions in the release notes (or jump in and fix them). Thanks. -- Daniel Bartholomew MariaDB - http://mariadb.org Monty Program - http://montyprogram.com AskMonty Knowledgebase - http://kb.askmonty.org

1 0

[Maria-developers] YaSSL upgrade
by Kristian Nielsen 10 Apr '12

10 Apr '12

Hi Serg, I'd like to discuss this bug with you when convenient (which may be next week, after the Percona Live conference :) https://bugs.launchpad.net/maria/+bug/977571 See my comments on the bug. In 5.3.6, we merged from mysql an upgrade of bundled yassl, and apparently this now conflicts with openssl loaded at the same time. I'd like to discuss with you if something can be done to avoid this conflict - though it might be that this is unavoidable, and the solution is just to link openssl dynamically. - Kristian.

1 0

[Maria-developers] MariaDB 5.3.6 release
by Daniel Bartholomew 08 Apr '12

08 Apr '12

All, I've uploaded the packages for MariaDB 5.3.6 to the primary mirror. I've also created initial Release Notes and Changelog pages for the release. They are located here: * http://kb.askmonty.org/en/mariadb-536-release-notes * http://kb.askmonty.org/en/mariadb-536-changelog Please let me know ASAP about anything which should be mentioned in the release notes, or if there are any changes which need to be made. My plan is to activate the release tomorrow morning (9 Apr) before I leave to travel to the user conference. I have an early flight, so it will be at around 04:00, U.S. Eastern Time. Thanks. -- Daniel Bartholomew MariaDB - http://mariadb.org Monty Program - http://montyprogram.com AskMonty Knowledgebase - http://kb.askmonty.org

1 0

Re: [Maria-developers] [Commits] Rev 3145: MDEV-80 Memory engine table full at much less than max_heap_table_size with btree index. in file:///home/hf/wmar/mdev80/
by Sergei Golubchik 06 Apr '12

06 Apr '12

Hi, Holyfoot! So, does that mean you've managed to reproduce the bug? Or you just found a possible cause for such a behavior and fixed it? On Apr 05, holyfoot(a)askmonty.org wrote: > revno: 3145 > revision-id: holyfoot(a)askmonty.org-20120405082116-w4xqjil2adoq12r3 > parent: sergii(a)pisem.net-20120404134150-6bonhsdqyrxjhku5 > committer: Alexey Botchkov <holyfoot(a)askmonty.org> > branch nick: mdev80 > timestamp: Thu 2012-04-05 13:21:16 +0500 > message: > MDEV-80 Memory engine table full at much less than max_heap_table_size with btree index. > RB-tree index in the MEMORY table fails if it grews over 4G. > That happened because the old_allocated variable in hp_rb_write_key() > had the uint type. Changed with the 'size_t' type to be same as the > 'rb_tree.allocated'. > > per-file comments: > storage/heap/hp_write.c > MDEV-80 Memory engine table full at much less than max_heap_table_size with btree index. > uint->size_t for the 'old_allocated'. Regards, Sergei

2 3

[Maria-developers] MariaDB 5.1.62 and 5.2.12 releases
by Daniel Bartholomew 06 Apr '12

06 Apr '12

All, I've uploaded the packages for MariaDB 5.1.62 and 5.2.12 to the primary mirror. I've also created initial Release Notes and Changelog pages for the releases. These releases are happening now because they include an important security fix. MariaDB 5.1.62: * http://kb.askmonty.org/en/mariadb-5162-release-notes * http://kb.askmonty.org/en/mariadb-5162-changelog MariaDB 5.2.12: * http://kb.askmonty.org/en/mariadb-5212-release-notes * http://kb.askmonty.org/en/mariadb-5212-changelog Please let me know ASAP about anything which should be mentioned in the release notes. My current plan is to give the mirrors some time to pull from the primary mirror and then activate the releases on Friday morning (6 April, US Eastern time). Thanks. -- Daniel Bartholomew MariaDB - http://mariadb.org Monty Program - http://montyprogram.com AskMonty Knowledgebase - http://kb.askmonty.org

1 0

Re: [Maria-developers] [Commits] Rev 3488: Fix of LP bug#968720. in file:///home/bell/maria/bzr/work-maria-5.3-lpb968720/
by Igor Babaev 05 Apr '12

05 Apr '12

Sanja, Please correct the comment (see my variant below) and fix the problem in cut() I discovered. Sorry, I basically don't understand your code. Contact me on IRC please. Regards, Igor. On 04/04/2012 04:01 AM, sanja(a)montyprogram.com wrote: > At file:///home/bell/maria/bzr/work-maria-5.3-lpb968720/ > > ------------------------------------------------------------ > revno: 3488 > revision-id: sanja(a)montyprogram.com-20120404110135-7eca0tt18auum3xo > parent: monty(a)askmonty.org-20120402092715-4cwn2rrcdeafir0x > committer: sanja(a)montyprogram.com > branch nick: work-maria-5.3-lpb968720 > timestamp: Wed 2012-04-04 14:01:35 +0300 > message: > Fix of LP bug#968720. > > Problem: > During converting from merged to materialized all items listed in used_item list changed from real tables to When a view/derived table is converted from merged to materialized the items from the used_item lists are substituted for items referring to the fields of the result of the materialization. The problem appeared with queries employing natural joins. Since the resolution of a natural join was performed only once the used_item list formed at the second execution of the query lacked the references to the fields that were used only in the equality predicates generated for the natural join. the temporary table of materialized join. The problem was that natural join matching made only once and on second prepare phase (first is prepare opf PREPARE statement, second is prepare phase of executing the statement) the list lack fields of natural join because it is not made second time. > > Solution: > Save the used_items list after natural join matching and restore it during re-initialization. > > > > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits + /* + Save the lists made during natural join matching (because + the matching done only once but we need the list in case + of prepared statements). + */ ^ remove this comment altogether. + table_ref_1->save_used_items= table_ref_1->used_items; + table_ref_2->save_used_items= table_ref_2->used_items; You save here the head of list only. Why? + ... + /** + Cut the list with leaving not more then n elements ^to leave + */ + inline uint cut(uint n) + { + list_node *element= first; + uint i= 0; + for (; + i < n && element != &end_of_list; + element= element->next); + if (element != &end_of_list) + { + elements= i + 1; + last= &element->next; + element->next= &end_of_list; + } + return i + 1; + } ^^^ i is initialized to 0. i is never changed. in this context the comparison i<n does not make any sense. + /* + Following is a bit hack but pointer length is equal everywhere + and we need revert pointers after prepared statement execution. + */ ^We need to restore the pointers after the execution of the prepared statement + thd->change_item_tree((Item **)&ref->ref, (Item*)materialized_items + idx);

1 0

Re: [Maria-developers] [Commits] Rev 3126: FIX for LP bug#956079 in file:///home/bell/maria/bzr/work-maria-5.2-lpb956079/
by Michael Widenius 03 Apr '12

03 Apr '12

Hi! >>>>> "sanja" == sanja <sanja(a)montyprogram.com> writes: sanja> At file:///home/bell/maria/bzr/work-maria-5.2-lpb956079/ sanja> ------------------------------------------------------------ sanja> revno: 3126 sanja> revision-id: sanja(a)montyprogram.com-20120319122824-7tnmdh8bq7cbnvni sanja> parent: sanja(a)montyprogram.com-20120314100903-a6txqk4l73smh189 sanja> committer: sanja(a)montyprogram.com sanja> branch nick: work-maria-5.2-lpb956079 sanja> timestamp: Mon 2012-03-19 14:28:24 +0200 sanja> message: sanja> FIX for LP bug#956079 sanja> Always set all callbacks for page cache. <cut> > --- a/storage/maria/ma_pagecache.c 2011-08-10 19:44:39 +0000 > +++ b/storage/maria/ma_pagecache.c 2012-03-19 12:28:24 +0000 > @@ -633,7 +633,6 @@ static my_bool pagecache_fwrite(PAGECACH > { > DBUG_ENTER("pagecache_fwrite"); > DBUG_ASSERT(type != PAGECACHE_READ_UNKNOWN_PAGE); > - > #ifdef EXTRA_DEBUG_BITMAP > /* > This code is very good when debugging changes in bitmaps or dirty lists > @@ -654,6 +653,12 @@ static my_bool pagecache_fwrite(PAGECACH > } > #endif > > + DBUG_ASSERT(filedesc->read_callback); > + DBUG_ASSERT(filedesc->write_callback); > + DBUG_ASSERT(filedesc->write_fail); > + DBUG_ASSERT(filedesc->flush_log_callback); Aren't the above callbacks guranteed to be set by the init code? If thats the case, there is no reason to test for these. There is no reason to test for read_callback or write_callback as we will always get a crash if these are not set (a few lines later). As we already test this in ma_pagecache.h, I think we can remove the DBUG_ASSERT's from ma_pagecache.c > === modified file 'storage/maria/ma_pagecache.h' > --- a/storage/maria/ma_pagecache.h 2011-02-28 17:39:30 +0000 > +++ b/storage/maria/ma_pagecache.h 2012-03-19 12:28:24 +0000 > @@ -271,6 +271,10 @@ extern void pagecache_set_write_on_delet > (F).read_callback= (RC); (F).write_callback= (WC); \ > (F).write_fail= (WF); \ > (F).flush_log_callback= (GLC); (F).callback_data= (uchar*)(D); \ > + DBUG_ASSERT((F).read_callback); \ > + DBUG_ASSERT((F).write_callback); \ > + DBUG_ASSERT((F).write_fail); \ > + DBUG_ASSERT((F).flush_log_callback); \ > } while(0) The above is good! It would of course be good to always use the function pagecache_file_init() to set all callbacks instead of setting these directly. To do this, you could change ma_open.c:: _ma_set_data_pagecache_callbacks() to use the above function instead of setting these directly. This way we would know for sure that either none or all are set and we don't need to do any DBUG_ASSERT() of these elements in the code. Regards, Monty

1 0

[Maria-developers] Please test: fix for BUG#913030
by Sergei Petrunia 02 Apr '12

02 Apr '12

Hi Elena, I need a separate test run of semi-join subquery tests on this branch: bzr+ssh://bazaar.launchpad.net/~maria-captains/maria/5.3-bug913030 I need it because the bugfix in this branch changes the order in which join optimizer considers query plans for semi-join subqueries. For synthetic data that RQG works on, this can have an effect that the query plans that were not choosen before will not be used. BUG#913030 is a high-priority 5.3 bug, so this is fairly urgent. BR Sergei -- Sergei Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

1 0