April 2012 - developers - lists.mariadb.org

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