- developers - lists.mariadb.org

Re: [Maria-developers] Fwd: [Commits] Rev 3622: Fix for MDEV-4140 in file:///home/tsk/mprog/src/5.3-md4140/
by Igor Babaev 06 Feb '13

06 Feb '13

Timour, It's ok to push this patch as a fix. Yet remember that this fix leads us to a performance regression 5.2 >> 5.3 when the range expression contains a constant [single-row] subquery. This is due to the changes when and how we build range trees in 5.3. When we have a range expression with constant expensive subquery we just bail out and do not include this range into the range condition at all. The worst thing about this is that we bail out even for dynamic ranges belonging to te range trees that are build at the execution time when subquery evaluation is allowed. Please open a task to fix all these regressions (it's quite possible). Regards, Igor. On 02/06/2013 03:27 AM, Timour Katchaounov wrote: > Igor, > > please review the following simple patch. > > Timour > > ------------------------------------------------------------ > revno: 3622 > revision-id: timour(a)askmonty.org-20130206112530-nwo4xto0cwv65ece > parent: sergii(a)pisem.net-20130128081223-mp9rsd3t9soz8lly > fixes bug(s): https://mariadb.atlassian.net/browse/MDEV-4140 > committer: timour(a)askmonty.org > branch nick: 5.3-md4140 > timestamp: Wed 2013-02-06 13:25:30 +0200 > message: > Fix for MDEV-4140 > > Analysis: > Range analysis detects that the subquery is expensive and doesn't > build a range access method. Later, the applicability test for loose > scan doesn't take that into account, and builds a loose scan method > without a range scan on the min/max column. As a result loose scan > fetches the first key in each group, rather than the first key that > satisfies the condition on the min/max column. > > Solution: > Since there is no SEL_ARG tree to be used for the min/max column, > it is not possible to use loose scan if the min/max column is compared > with an expensive scalar subquery. Make the test for loose scan > applicability to be in sync with the range analysis code by testing if > the min/max argument is compared with an expensive predicate. > >

1 0

[Maria-developers] MariaDB 10.0.1-alpha release prep
by Daniel Bartholomew 06 Feb '13

06 Feb '13

I've begun prepping MariaDB 10.0.1-alpha for release. Preliminary changelog and release notes are here: - https://kb.askmonty.org/en/mariadb-1001-release-notes/ - https://kb.askmonty.org/en/mariadb-1001-changelog/ I saw in the changelog a couple of features on https://kb.askmonty.org/en/what-is-mariadb-100/ that were added in this release (MDEV-4011 & Cassandra Storage Engine), if there are other new features, or features backported from MySQL 5.6, or anything else I should be sure to mention in the release notes, please let me know ASAP. Thanks. -- Daniel Bartholomew Google+ - http://gplus.to/dbart Twitter - http://twitter.com/daniel_bart MariaDB: An Enhanced Drop-in Replacement for MySQL Website - http://mariadb.org Twitter - http://twitter.com/mariadb Google+ - http://google.com/+mariadb Facebook - http://fb.com/MariaDB.dbms Knowledgebase - http://kb.askmonty.org Monty Program - http://montyprogram.com

3 4

[Maria-developers] mariadb-server not installable on Debian Testing AMD64
by Thomas Hackert 05 Feb '13

05 Feb '13

SEND-PR: -*- send-pr -*- SEND-PR: Lines starting with `SEND-PR' will be removed automatically, as SEND-PR: will all comments (text enclosed in `<' and `>'). SEND-PR: From: thackert(a)nexgo.de To: maria-developers(a)lists.launchpad.net Subject: mariadb-server not installable on Debian Testing AMD64 >Description: Hello @ll, this is my first try to report a bug with mysqlbug. If I missed something and/or have something wrong, feel free to ask, but do not condemn me ... ;) I have tried to install mariadb-server on Debian Testing AMD64. I got the error message <quote> <snip> [ ok ] Stopping MariaDB database server: mysqld. 130130 17:28:50 [Note] Plugin 'InnoDB' is disabled. 130130 17:28:50 [Note] Plugin 'FEEDBACK' is disabled. [....] Starting MariaDB database server: mysqld . . . . . . . . . . . . . . . . . . . . FAIL . . . . . . . failed! invoke-rc.d: initscript mysql, action "start" failed. dpkg: Fehler beim Bearbeiten von mariadb-server-10.0 (--configure): Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück dpkg: Abhängigkeitsprobleme verhindern Konfiguration von mariadb-server: mariadb-server hängt ab von mariadb-server-10.0; aber: Paket mariadb-server-10.0 ist noch nicht konfiguriert. dpkg: Fehler beim Bearbeiten von mariadb-server (--configure): Abhängigkeitsprobleme - verbleibt unkonfiguriert Trigger für menu werden verarbeitet ... Fehler traten auf beim Bearbeiten von: mariadb-server-10.0 mariadb-server </quote> ... :( I get the same message, if I try to install mysql-server from Debian's repository ... :( >How-To-Repeat: 1. Add " # MariaDB 10.0 repository list - created 2013-01-30 16:20 UTC # http://mariadb.org/mariadb/repositories/deb # http://mirror.netcologne.de/mariadb//repo/10.0/debian wheezy main deb-src http://mirror.netcologne.de/mariadb//repo/10.0/debian wheezy main" to your /etc/apt/sources.list. 2. Run "apt-get update" 3. Run "apt-get install mariadb-server" The error message appears nearly at the end of the installation ... :( >Fix: I do not know, sorry ... :( But maybe it is possible to check first, if mysql- or mariadb-server was installed before, and if it was, stop it. If it was not installed before, than it should not try to stop the server ... ;) >Submitter-Id: <submitter ID> >Originator: Thomas Hackert >Organization: <none> >MySQL support: [none | licence | email support | extended email support >] >Synopsis: mariadb-server not installable on Debian Testing AMD64 >Severity: serious >Priority: medium >Category: mysql >Class: <[ sw-bug | doc-bug | change-request | support ] (one >line)> >Release: mysql-10.0.0-mariadb1~wheezy (mariadb.org binary >distribution) >C compiler: gcc-4.7.real (Debian 4.7.1-2) 4.7.1 >C++ compiler: g++-4.7.real (Debian 4.7.1-2) 4.7.1 >Environment: <machine, os, target, libraries (multiple lines)> System: Linux neo 3.2.0-4-amd64 #1 SMP Debian 3.2.35-2 x86_64 GNU/Linux Some paths: /usr/bin/perl /usr/bin/make /usr/bin/gcc /usr/bin/cc GCC: Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enanable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.7.2 (Debian 4.7.2-5) Compilation info (call): CC='/usr/bin/gcc' CFLAGS='-O2 -fno-omit-frame-pointer -g -pipe -Wall -Wno-uninitialized -O3 -g -static-libgcc -fno-omit-frame-pointer -fno-strict-aliasing -DDBUG_OFF -DMY_PTHREAD_FASTMUTEX=1' CXX='/usr/bin/g++' CXXFLAGS='-O2 -fno-omit-frame-pointer -g -pipe -Wall -Wno-uninitialized -fno-exceptions -fno-rtti -O3 -g -static-libgcc -fno-omit-frame-pointer -fno-strict-aliasing -DDBUG_OFF -DMY_PTHREAD_FASTMUTEX=1' LDFLAGS='' ASFLAGS='' Compilation info (used): CC='/usr/bin/gcc' CFLAGS='-O2 -fno-omit-frame-pointer -g -pipe -Wall -Wno-uninitialized -O3 -g -static-libgcc -fno-omit-frame-pointer -fno-strict-aliasing -DDBUG_OFF -DMY_PTHREAD_FASTMUTEX=1' CXX='/usr/bin/g++' CXXFLAGS='-O2 -fno-omit-frame-pointer -g -pipe -Wall -Wno-uninitialized -fno-exceptions -fno-rtti -O3 -g -static-libgcc -fno-omit-frame-pointer -fno-strict-aliasing -DDBUG_OFF -DMY_PTHREAD_FASTMUTEX=1' LDFLAGS='' ASFLAGS='' Perl: This is perl 5, version 14, subversion 2 (v5.14.2) built for x86_64-linux-gnu-thread-multi -- The way to make a small fortune in the commodities market is to start with a large fortune.

3 7

Re: [Maria-developers] [Maria-discuss] Files under /etc/my.cnf.d/ read by default
by Honza Horak 05 Feb '13

05 Feb '13

This should have been posted better to maria-developers, probably, so re-sending.. On 02/05/2013 01:55 PM, Honza Horak wrote: > Hi guys, > > while we were packaging MariaDB into Fedora (finally) we used the > upstream's cnf files structure, which means /etc/my.cnf, that includes > all files from directory /etc/my.cnf.d/* using statement !includedir. > > That works fine when user installs (not updates) the MariaDB packages > without having them installed before. The problem is if user has changed > /etc/my.cnf before updating -- then /etc/my.cnf doesn't get updated > (!includedir won't be added) and we end with files under /etc/my.cnf.d/* > but nothing what includes them. That is quite confusing for users that > may change something in /etc/my.cnf.d/client.cnf but nothing happens. > > Since files under /etc/my.cnf.d/* are empty by default it shouldn't do > any harm if all files corresponding with /etc/my.cnf.d/*.cnf template > get loaded even without !includedir in /etc/my.cnf. Actually I believe > that is what users expect to happen when they see files under > /etc/my.cnf.d.. > > So, that's basically what I'm proposing -- read files under > /etc/my.cnf.d/* by default, without a need to use !includedir. What do > you think? > > Regards, > Honza > > _______________________________________________ > Mailing list: https://launchpad.net/~maria-discuss > Post to : maria-discuss(a)lists.launchpad.net > Unsubscribe : https://launchpad.net/~maria-discuss > More help : https://help.launchpad.net/ListHelp

1 0

[Maria-developers] InnoDB Compression
by Gordan Bobic 04 Feb '13

04 Feb '13

Hi, I've just tried testing InnoDB page compression, and I'm sure I must be doing something wrong because the disk space usage in my database directory is the same before and after the compression. To compress the tables I am using: ALTER TABLE $table ENGINE=InnoDB ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=$size; with $size I tried being 8KB and 4KB, and in each case "du -h" on the DB directory is the same as before the compression. innodb_file_per_table is set. SHOW CREATE TABLE afterwards shows the ROW_FORMAT and KEY_BLOCK_SIZE to be as per the ALTER TABLE statement. 1) Am I doing it wrong? 2) Is the InnoDB compression feature available in MariaDB? 3) Is the compression on by default transparently? 4) Is there any other explanation for lack of effect? As a cross-check, I tried taking my biggest .ibd file and compressing it with "lzop -1" and that compressed it from 80MB down to 22MB, which doesn't sound right if the data in it was already compressed in any way. Has anybody got any possible explanations? TIA Gordan

2 2

Re: [Maria-developers] [Commits] Rev 3657: MDEV-4127 : Export additional symbols when building RPM
by Sergei Golubchik 04 Feb '13

04 Feb '13

Hi, Vladislav! May be you'd rather rename symbols with #define, just as redhat does? On Feb 03, Vladislav Vaintroub wrote: > At file:///H:/bzr/5.5/ > > ------------------------------------------------------------ > revno: 3657 > revision-id: wlad(a)montyprogram.com-20130203164516-ex2ftmyca5b507g3 > parent: elenst(a)ubuntu11.home-20130202225357-za9bglcf2ngv36xj > committer: Vladislav Vaintroub <wlad(a)montyprogram.com> > branch nick: 5.5 > timestamp: Sun 2013-02-03 17:45:16 +0100 > message: > MDEV-4127 : Export additional symbols when building RPM, > to enable both recompiling mysqli or odbc from sources in addition > to drop-in replacement functionality. > > The case in question is compiling mysqli from sources, that needs > client_errors via ER() macro. > > Previously, we exported it as mysql_client_errors (compatibly to > Fedora's style symbol renaming, see MDEV-3842). > However, if MariaDB header files are used when compiling mysqli, > client_errors needs to be exported with its original name. Regards, Sergei

2 2

[Maria-developers] Coverity scans of MariaDB source
by Christian Convey 04 Feb '13

04 Feb '13

Coverity has a deal called Coverity Scan, where they offer free static analyses of open-source programs (http://scan.coverity.com/) I've used Coverity Prevent at work, and I was pretty happy with the analyses it performed. Is it an intentional choice that MariaDB isn't making use of Coverity Scan? I'm interested in starting to contribute to MariaDB, and I'm wondering if it would be useful to the project for me to pursue this as a first task. - Christian

2 2

[Maria-developers] CMake vs. autotools on Linux?
by Christian Convey 04 Feb '13

04 Feb '13

Hi guys, I noticed that MariaDB is built (indirectly) with CMake on Windows, and with autotools on Linux. Why are both systems used? I would have assumed that because CMake is pretty good at generating Makefiles on Linux and OS X, there would be little reason to continue using autotools. Thanks, Christian

2 3

Re: [Maria-developers] Summary of the MDEV-3882 (.deb upgrade from mysql to mariadb fails due to apt-get considering it a downgrade)
by Kristian Nielsen 02 Feb '13

02 Feb '13

[Moving the discussion to maria-developers@, please use the public mailing lists for discussions like this] Alexey Botchkov <holyfoot(a)askmonty.org> writes: > No matter what dependencies or new packages i created inside MariaDB, > Debian's first idea was to try to install the 'later' version of > libmysqlclient18. At the moment > that was the Oracle's one. Yes, we could change our version's number to be > 'later' than Oracle's, but that would turn same problems on MySQL, and Not really. It's not "Oracle's", it is the native Debian/Ubuntu package. So if users want MariaDB, they can add our repository. If they want the official Debian/Ubuntu package, they can just not add our repository. So it makes sense that when users explicitly add the MariaDB repository, they get the MariaDB version of all the packages automatically. > would help us only temporarely - to the moment Oracle releases even > later' version. We can use epoch to ensure that our version will always be bigger than the official Debian/Ubuntu version of MySQL: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version Something like 1:5.5.29-mariadb1~wheezy. This will always be prefered by apt-get over any official Debian package. > I didn't find anything that could affect apt-get and guys on #Debian > didn't recommend anything. I believe it works to specify desired version explicitly, as mentioned in the bug report as workaround: sudo apt-get install mariadb-server libmysqlclient18=5.5.29-mariadb1~wheezy > So for now i'd do about this: > - change nothing in the existing mariadb-produced debian packages. > - recommend to use 'aptitude' installing the mariadb-server on Debian. > So how do you like my proposal? Any other ideas? I think it is better if we use the epoch to make MariaDB upgrades work automatically with both apt-get and aptitude, like they used to. Did you check how Percona handles the similar problem? - Kristian.

2 1

Re: [Maria-developers] Fwd: [Commits] Rev 3622: Analysis: in file:///home/tsk/mprog/src/5.3-md641/
by Igor Babaev 31 Jan '13

31 Jan '13

On 01/31/2013 04:41 AM, Timour Katchaounov wrote: > Igor, > > Let me know if I can push the patch below. It fixes the bug > according to our last discussion. If the number of group_list > elements was known, I could add a test already in the beginning > of the function, however such a counter doesn't exist, and I > didn't want to complicate the code just for this special case. > That's why the test is done where it is now. > > Timour > > > ------------------------------------------------------------ > revno: 3622 > revision-id: timour(a)askmonty.org-20130131120040-oan9zei8ojyco178 > parent: sergii(a)pisem.net-20130128081223-mp9rsd3t9soz8lly > fixes bug(s): https://mariadb.atlassian.net/browse/MDEV-641 > committer: timour(a)askmonty.org > branch nick: 5.3-md641 > timestamp: Thu 2013-01-31 14:00:40 +0200 > message: > Analysis: > Range analysis discoveres that the query can be executed via loose > index scan for GROUP BY. > Later, GROUP BY analysis fails to confirm that the GROUP operation can > be computed via an > index because there is no logic to handle duplicate field references > in the GROUP clause. > As a result the optimizer the optimizer produces an inconsistent plan. > It constructs a > temporary table, but on the other hand the group fields are not set to > point there. > > Solution: > Make loose scan analysis work in sync with order by analysis. In the > case of duplicate > columns loose scan will not be applicable. This limitation will be > lifted in 10.0 by > removing duplicate columns. > >

1 0