- developers - lists.mariadb.org

Re: [Maria-developers] [Commits] Rev 2833: Fixed LP bug #664508. in file:///home/igor/maria/maria-5.3-mwl128-bug664508/
by Sergey Petrunya 21 Feb '11

21 Feb '11

Hello Igor, On Sun, Oct 24, 2010 at 02:22:02PM -0700, Igor Babaev wrote: > At file:///home/igor/maria/maria-5.3-mwl128-bug664508/ > > ------------------------------------------------------------ > revno: 2833 > revision-id: igor(a)askmonty.org-20101024212201-t8iius4jikcvm3zb > parent: igor(a)askmonty.org-20101022223047-phunrh5g3xzrx2d9 > committer: Igor Babaev <igor(a)askmonty.org> > branch nick: maria-5.3-mwl128-bug664508 > timestamp: Sun 2010-10-24 14:22:01 -0700 > message: > Fixed LP bug #664508. > When join buffers are employed no index scan for the first > table with grouping columns can be used. ... > === modified file 'sql/sql_select.cc' > --- a/sql/sql_select.cc 2010-10-18 20:56:48 +0000 > +++ b/sql/sql_select.cc 2010-10-24 21:22:01 +0000 > @@ -7980,8 +7980,11 @@ > JOIN_TAB *tab=join->join_tab+i; > if (tab->use_join_cache) > { > - JOIN_TAB *sort_by_tab= join->get_sort_by_join_tab(); > - if (sort_by_tab && !join->need_tmp) > + JOIN_TAB *sort_by_tab= join->group && join->simple_group && > + join->group_list ? > + join->join_tab+join->const_tables : > + join->get_sort_by_join_tab(); > + if (sort_by_tab) > { > join->need_tmp= 1; > join->simple_order= join->simple_group= 0; Here sort_by_tab is assigned inside the " for (i=join->const_tables ; ..." loop. I think the code will look much more cleaner if it was calculated before the loop (and actually we don't need to loop at all if sort_by_tab==NULL). > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits -- BR Sergey -- Sergey Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

1 0

[Maria-developers] MariaDB Binary Log File Corruption
by Daniel Bartholomew 20 Feb '11

20 Feb '11

Hello everyone, I came across this question in the Knowledgebase: http://kb.askmonty.org/v/binary-log-file-corruption-happens-each-day The poster was able to solve the problem by increasing the slave max_allowed_packet size from 32M to 256M. Any thoughts from the list about this? My guess is that this not a MariaDB-specific thing; just a difference between 5.0 and 5.1 (and higher). But I'm asking anyway in case I'm mistaken and/or if a note should be added to the documentation for max_allowed_packet. Thanks. -- Daniel Bartholomew MariaDB - http://mariadb.org Monty Program - http://montyprogram.com AskMonty Knowledgebase - http://kb.askmonty.org

2 1

[Maria-developers] question about when locks are released
by MARK CALLAGHAN 18 Feb '11

18 Feb '11

Vamsi, In the innodb-release-locks-early patch, do you remember why you release the locks only _after_ the sync in prepare(), and not before? -- Mark Callaghan mdcallag(a)gmail.com

1 1

[Maria-developers] WL#176 New (by Dreas): protocl typo in replication error
by worklog-noreply＠askmonty.org 17 Feb '11

17 Feb '11

----------------------------------------------------------------------- WORKLOG TASK -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- TASK...........: protocl typo in replication error CREATION DATE..: Thu, 17 Feb 2011, 16:58 SUPERVISOR.....: IMPLEMENTOR....: COPIES TO......: CATEGORY.......: Maria-RawIdeaBin TASK ID........: 176 (http://askmonty.org/worklog/?tid=176) VERSION........: WorkLog-4.0 STATUS.........: Un-Assigned PRIORITY.......: 10 WORKED HOURS...: 0 ESTIMATE.......: 0 (hours remain) ORIG. ESTIMATE.: 0 PROGRESS NOTES: DESCRIPTION: Using 5.1.50-mariadb84: ===== Last_IO_Error: error connecting to master 'repl2@mysql1.*****.com:3306' - retry- time: 60 retries: 86400 message: SSL error: protocl version mismatch ==== "protocl" seems to be a typo. ESTIMATED WORK TIME ESTIMATED COMPLETION DATE ----------------------------------------------------------------------- WorkLog (v4.0.0)

1 0

[Maria-developers] work in progress for the Facebook patch
by MARK CALLAGHAN 16 Feb '11

16 Feb '11

I am writing this to describe work in progress for the Facebook patch. Comments are welcome. In the future we hope to get parts of the Facebook patch into public forks. We have two big projects in progress: * admission control * InnoDB compression for OLTP --- Admission control enforces max concurrent queries per account. MySQL already limits max concurrent connections per account, but we want to set the connection limit to a much larger value than the query limit. The limit will be enforced at statement start and will allow queries to timeout in the queue while waiting to run. By "descheduled" I mean that a connection decrements the count of concurrent queries for a particular account. Connections will be descheduled when: * a statement ends * a connection is about to send results back to a client -- only when the socket write is to be done, not when data is buffered * srv_suspend_mysql_thread is called on a row lock wait * possibly when a disk read is done within innodb * when enter_cond is called By "scheduled" I mean that a connection increments the count of concurrent queries for an account. If done with "noforce" then the caller will wait until this doesn't exceed concurrency limits for the account. If done with "force" then this doesn't wait and can exceed the concurrency limits. Schedule with noforce is done: * at statement start * after a socket write Schedule with force is done: * when exit_cond is called * when a thread wakes after calling srv_suspend_mysql_thread This change will allow us to run with higher values for max concurrent connections and we assume that will significantly increase mutex contention on kernel_mutex so we have begun to evaluate: * using the pthread mutex implementation that does not spin in more cases * limit the max number of threads that can do concurrent busy-wait loops for InnoDB's mutex and rw-lock * removing use of the sync array within InnoDB * changing Innodb to wake one rather than all waiters when a mutex is unlocked * somehow making read_view_open_now faster --- InnoDB compression for OLTP tries to make compression faster for OLTP workloads. We have work in progress to change InnoDB to not log page images for many but not all insert/update/delete operations. When InnoDB compression is used, InnoDB can log page images. That was not done before and for my production workloads this doubles the rate at which IO is done to the transaction log and increases the dirty page write rate by at least 20% because checkpoint IO must be done sooner. We previously added an option that allows the LZ compression level to be set globally. I think the default is level 6. We will evaluate: * using QuickLZ which provides faster compression and decompression than zlib * adding compress_ops and compress_ops_ok per table to information_schema.table_statistics * adding an option to limit compression to the clustered index and not compress secondary indexes -- Mark Callaghan mdcallag(a)gmail.com

1 0

[Maria-developers] MariaDB and MySQL 5.5
by MARK CALLAGHAN 11 Feb '11

11 Feb '11

When will there be a MariaDB branch based on MySQL 5.5? I want to use that as the basis for the 5.5 version of the Facebook patch. -- Mark Callaghan mdcallag(a)gmail.com

2 1

[Maria-developers] WL#175 New (by Mdcallag): Unique ID in binlog event metadata
by worklog-noreply＠askmonty.org 11 Feb '11

11 Feb '11

----------------------------------------------------------------------- WORKLOG TASK -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- TASK...........: Unique ID in binlog event metadata CREATION DATE..: Fri, 11 Feb 2011, 05:03 SUPERVISOR.....: IMPLEMENTOR....: COPIES TO......: CATEGORY.......: Server-RawIdeaBin TASK ID........: 175 (http://askmonty.org/worklog/?tid=175) VERSION........: Server-9.x STATUS.........: Un-Assigned PRIORITY.......: 60 WORKED HOURS...: 0 ESTIMATE.......: 0 (hours remain) ORIG. ESTIMATE.: 0 PROGRESS NOTES: DESCRIPTION: While I would love to have global transaction IDs for MySQL replication (http://askmonty.org/worklog/Server-RawIdeaBin/?tid=31) that is a huge project. I think we can automate slave failover if binlog events have a metadata attribute that is a unique ID and that metadata is sticky like server ID when a slave is run with --log-slave-updates. Assuming this metadata is added, when it is time to do slave failover, first determine the serverID + uniqueID for the last binlog event group executed on the slave, then find that filename/offset for that event on the new master, then CHANGE MASTER on the slave to start replication on the new master just past that offset. I mention that serverID can be used in addition to the uniqueID, so maybe uniqueID only needs to be unique within the binlog events generated for one serverID. The search on the new master is more efficient when the uniqueID are generated in increasing order. But I am not sure whether that is required. We might need a new server command that maps (serverID, uniqueID) to (filename, offset), but I am not sure that is required. ESTIMATED WORK TIME ESTIMATED COMPLETION DATE ----------------------------------------------------------------------- WorkLog (v4.0.0)

1 0

Re: [Maria-developers] Windows installer MWL#55 finished.
by Vladislav Vaintroub 08 Feb '11

08 Feb '11

> -----Original Message----- > From: kahzoo(a)gmail.com [mailto:kahzoo@gmail.com] On Behalf Of Kazuhisa > Ichikawa > Sent: Dienstag, 8. Februar 2011 04:46 > To: Vladislav Vaintroub > Cc: Philip Stoev; maria-developers(a)lists.launchpad.net > Subject: Re: [Maria-developers] Windows installer MWL#55 finished. > > Hello, Vladislav. > All previous 5.2.5 installer created its data directory even when > upgrading existing instance. Therefore, if datadir was not set > explicity in the inherited my.ini, it was using the new data directory > (in other words, it was not reusing the previous database files, I'm > afraid). Yes. Somewhat unusual case my.ini without datadir was not handled correctly though (case without my.ini at all was handled). Fixed that, MSIs are in the usual location. Thanks for input! > - Kazuhisa

1 0

Re: [Maria-developers] Windows installer MWL#55 finished.
by Vladislav Vaintroub 05 Feb '11

05 Feb '11

> -----Original Message----- > From: kahzoo(a)gmail.com [mailto:kahzoo@gmail.com] On Behalf Of Kazuhisa > Ichikawa > Sent: Samstag, 5. Februar 2011 04:34 > To: Vladislav Vaintroub > Cc: maria-developers(a)lists.launchpad.net > Subject: Re: [Maria-developers] Windows installer MWL#55 finished. Hello Kazuhisa, > I BROWSED through it but did not read it carefully line by line before > reporting bugs. Sorry about that. Yet, all of your reports were valid . > > By the way, after finished installing 5.2.5 and upgrading the previous > (5.1.53) service instance, I have 2 service definitions for 5.2.5, one > that was newly created and the other that was successfully upgraded > from 5.1.53. > > I think this is a human (that is my) error rather than a bug, because > I checked "Install as service" in the "Defaults settings" dialog > before the installer starts installing 5.2.5 files and then chose to > upgrade the existing service in the Upgrade Wizard that was started > after installation. If you think installing instance was a mistake on you part (you only wanted to upgrade what you have), you can correct that easily. In maintenance mode install (Add/Remove Programs=>MariaDB5.2=>Change/Uninstall), select "Change" button. Deselect "Database Instance". Choose "Remove data" afterwards. Now the mistakenly installed instance is gone. > My expectation was that the installer and upgrade > wizard will install a new service instance based on the information > from the existing service definition. Hmm, have you see that in any of MySQL installers ;)? > If I could (mutually) exclusively select between "installing a new > service" and "upgrading from existing service" in the same dialog, I > could have avoided this mis-configuration. I understand, and agree from usability point of view this would be ideal. Currently, "Database Instance" feature can only create new databases, while "Upgrade Wizard" (runs outside of the installer) upgrades existing instances. Their functionality is non-overlapping. This allows for painless (for user) and simple to implement installer rollback in case of errors. So it will stay this way for the version 1 of the new installer. One thing that is possible to do to handle your case, is to deselect "database instance" by default, if upgradable services are detected. I'm not sure this is the best way to handle it , and whether it would confuse the user thus I'll consult our QA for his opinion. Philip, what do you think? Vladislav

1 0

Re: [Maria-developers] Windows installer MWL#55 finished.
by Vladislav Vaintroub 04 Feb '11

04 Feb '11

> -----Original Message----- > From: kahzoo(a)gmail.com [mailto:kahzoo@gmail.com] On Behalf Of Kazuhisa Ichikawa > Sent: Freitag, 4. Februar 2011 03:17 > To: Vladislav Vaintroub > Cc: maria-developers(a)lists.launchpad.net > Subject: Re: [Maria-developers] Windows installer MWL#55 finished. > > Hello Vladislav, Hello Kazuhisa, > First of all, thanks for all the information on "MSI v.s. NSIS" issues. > > > On a bright side, this is a valid bug that was simple to fix forcing per-machine install, so installer does not need to guess. I > > did that and refreshed the MSI on the download page. > > I confirmed the fix with the same machine/user with which I had the > original problem. Thanks. > > However, I'm afraid I hit a new one. If I have MariaDB 5.1.53 > installed (by the 5.1 installer) on the same machine, the new > installer doesn't allow me to install 5.2.5 saying: > "Previous version of MariaDB was found, that used incompatible > installer. Please remove "MariaDB 5.1.53" before you proceed with this > installation." Ok, valid bug. Thanks for reporting. There will *still* be this message if you're trying to install 5.2.5 msi with existing 5.2.(<5) NSIS . For me personally ,main reason NOT to offer 5.2.4=>5.2.5 autoupgrade is the fact that MariaDBs NSIS was not designed to run in silent mode, its popups "Directory not deleted" during upgrade would only alienate users . > I think this is not an intended behavior, because this kills the big > benefit (of your new installer) of automatically upgrading older > MariaDB instance. The upgrade is not always automatic, sometimes it is semiautomatic (supported by the UI tool launched at the end of installation). Did you look in the WL on how upgrades are handled? Here is link just in case http://askmonty.org/worklog/Server-Sprint/?tid=55 . Feedback on it is welcome. I have fixed 5.2.5 over 5.1 NSIS installation ,the update is on usual place. http://cid-ff0c950417b4f8a4.office.live.com/browse.aspx/share Thanks for your efforts, Vladislav

2 3