[Maria-developers] Missing man/mysql_plugin.1 in tar ball
Hi all, I've noticed that man page for mysql_plugin utility (man/mysql_plugin.1) is not present in mariadb-5.5.28a.tar.gz while it is present in mysql-5.5.28.tar.gz. However, I failed to find the reason why in case there is one. Or is that a mistake? Does anybody know? Regards, Honza ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Maria-discuss] Files under /etc/my.cnf.d/ read by default
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-disc...@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Files under /etc/my.cnf.d/ read by default
On 02/06/2013 09:33 PM, Sergei Golubchik wrote: Hi, Honza! On Feb 05, 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. Agree. Especially as we've started to use /etc/my.cnf.d/ now - e.g. CassandraSE comes in a separate rpm, that (besides the plugin itself) drops a file into /etc/my.cnf.d/ to enable the engine in the server. I expect that more separately-packed plugins will start doing the same. 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? What if we add !includedir to the /etc/my.cnf from the post-inst script? Something like grep -q '!includedir /etc/my.cnf.d' /etc/my.cnf || \ (echo; echo '!includedir /etc/my.cnf.d') >> /etc/my.cnf Would that be enough? Thanks for that idea. It would work, but honestly I'm not sure if we want touch my.cnf during update. I've shared this idea with other fedora developers to collect their opinions -- feel free to join the discussion at: http://lists.fedoraproject.org/pipermail/devel/2013-February/178475.html Regards, Honza ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
[Maria-developers] C API for dynamic columns - in which versions?
Hi guys, I failed to find the info in which versions of MariaDB "C API for dynamic columns" is available as described here: https://kb.askmonty.org/en/dynamic-columns-api/ I think the information should be the best included directly on the page itself. Regards, Honza ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] C API for dynamic columns - in which versions?
And one additional question -- do I correctly understand that mariadb_dyncol_* function are in mariadb-10.x.x and dynamic_columns_* functions are in mariadb-5.5.x? In that case I'd propose to create a new page with API documentation of only dynamic_columns_*. Honza On 02/28/2013 04:45 PM, Honza Horak wrote: Hi guys, I failed to find the info in which versions of MariaDB "C API for dynamic columns" is available as described here: https://kb.askmonty.org/en/dynamic-columns-api/ I think the information should be the best included directly on the page itself. Regards, Honza ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
[Maria-developers] Forked mytop - conflicts, issues
Hi guys, MariaDB forked mytop utility source some time back, but it causes some issues for us in Fedora for example (and similarly in other distributions I guess) -- particularly the MariaDB's binary mytop conflicts with the same utility from separate package mytop. So, I'd like to take a look at possible solutions. Since there was a small commit in mytop upstream few weeks back, it doesn't really look like totally dead upstream. So the ideal solution from my POV would be including enhancements that MariaDB did to mytop back to upstream and not including mytop utility in MariaDB any more. Would something like that be possible from the perspective of MariaDB? Cheers, Honza ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
[Maria-developers] MariaDB 5.5 EOL plans
Hi guys, I'm not able to find any info about life cycle of MariaDB 5.5 or even other versions. Particularly if the MariaDB 5.5 life cycle will somehow follow the MySQL's 5.5 life cycle or if there is some another vision/rough plans when supporting of 5.5 will end? Cheers, Honza ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] MariaDB 5.5 EOL plans
On 05/24/2013 11:04 PM, Rasmus Johansson wrote: Hi, On Tue, May 14, 2013 at 5:57 PM, Honza Horak mailto:hho...@redhat.com>> wrote: Hi guys, I'm not able to find any info about life cycle of MariaDB 5.5 or even other versions. Particularly if the MariaDB 5.5 life cycle will somehow follow the MySQL's 5.5 life cycle or if there is some another vision/rough plans when supporting of 5.5 will end? Thanks for bringing this up! It has been on the table quite some times, but now finally I think we got it documented. So here it is: Thank you very much, that looks really great. Honza ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
[Maria-developers] 10.x compatibility and separate namespace
Hi Guys, since 10.x won't be compatible with mysql in every aspect any more, I'm wondering if there happen to be any plans to move all compatibility left-overs (client binary names, client library name, daemon binary name, etc.). Are there any such ideas? I understand that we would lose the compatibility for any later (keeping original names was mentioned in [1] as a MUST for compatibility), but when keeping the original names, it could become tricky to say which tools are compatible and which not any more in mariadb 10+. How this information will be provided actually? How to get users informed properly, which tools are not compatible any more? And a bit another POV -- is the incompatibility in 10.x strictly limited to the server only (so client side will stay compatible for anytime later)? [1] https://lists.launchpad.net/maria-discuss/msg00658.html Regards, Honza ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
[Maria-developers] MariaDB config files order
Hi guys, maybe I just need some little kick or I should get a coffee, but I can't understand the following config file ordering difference. Reading [1] and code in mariadb-5.5.32/mysys/default.c:1226, it looks like expected order of config files in Linux should be: /etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf However, when asking for that using --help --verbose, I get a bit different output: $ /usr/libexec/mysqld --help --verbose 2>/dev/null | grep --after=1 '^Default options' | tail -n 2 Default options are read from the following files in the given order: /etc/mysql/my.cnf /etc/my.cnf ~/.my.cnf I don't understand why /etc/my.cnf is not on the first place in that output. Can somebody give me a hint? Am I just blind? Just FTR I'm trying that on Fedora 19, but there are no changes in Fedora packages that would do anything related, so I guess the same result would be in other distros as well. [1] https://kb.askmonty.org/en/mysqld-startup-options/ Cheers, Honza ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] MariaDB config files order
On 08/13/2013 12:51 PM, Michael Widenius wrote: Hi! "Honza" == Honza Horak writes: Honza> Hi guys, Honza> maybe I just need some little kick or I should get a coffee, but I can't Honza> understand the following config file ordering difference. Honza> Reading [1] and code in mariadb-5.5.32/mysys/default.c:1226, it looks Honza> like expected order of config files in Linux should be: Honza> /etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf Honza> However, when asking for that using --help --verbose, I get a bit Honza> different output: Honza> $ /usr/libexec/mysqld --help --verbose 2>/dev/null | grep --after=1 Honza> '^Default options' | tail -n 2 Honza> Default options are read from the following files in the given order: Honza> /etc/mysql/my.cnf /etc/my.cnf ~/.my.cnf I checked this on my version of MariaDB (fresh from bzr) on OpenSuse: mysqld Ver 5.5.32-MariaDB-debug Default options are read from the following files in the given order: /etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf Honza> I don't understand why /etc/my.cnf is not on the first place in that Honza> output. Can somebody give me a hint? Am I just blind? I did check the mysqld version that comes with OpenSuse 12.3 and this gives: Default options are read from the following files in the given order: /etc/mysql/my.cnf /etc/my.cnf ~/.my.cnf This packet is named: mariadb-5.5.29-1.1.1.x86_64 and built by http://bugs.opensuse.org What is the version name of the libexec/mysqld that you got and who has built it? Can you get the source of the package ? Hi Monty, thanks for your explanation so far.. It's happening on all fedora packages I've tested, currently mariadb-5.5.31-4.fc19.src.rpm But when trying to build from downloaded tarball with various options I've found something interesting. When using "-DINSTALL_LAYOUT=RPM" in the cmake call, then the order is /etc/mysql/my.cnf /etc/my.cnf ~/.my.cnf but when *not* using "-DINSTALL_LAYOUT=RPM", then the order is /etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf I haven't found yet why is this happening, haven't spotted any significant #IF macro or anything what could cause this.. Maybe you have an idea? Cheers, Honza ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] MariaDB config files order
On 08/13/2013 06:20 PM, Honza Horak wrote: On 08/13/2013 12:51 PM, Michael Widenius wrote: Hi! "Honza" == Honza Horak writes: Honza> Hi guys, Honza> maybe I just need some little kick or I should get a coffee, but I can't Honza> understand the following config file ordering difference. Honza> Reading [1] and code in mariadb-5.5.32/mysys/default.c:1226, it looks Honza> like expected order of config files in Linux should be: Honza> /etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf Honza> However, when asking for that using --help --verbose, I get a bit Honza> different output: Honza> $ /usr/libexec/mysqld --help --verbose 2>/dev/null | grep --after=1 Honza> '^Default options' | tail -n 2 Honza> Default options are read from the following files in the given order: Honza> /etc/mysql/my.cnf /etc/my.cnf ~/.my.cnf I checked this on my version of MariaDB (fresh from bzr) on OpenSuse: mysqld Ver 5.5.32-MariaDB-debug Default options are read from the following files in the given order: /etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf Honza> I don't understand why /etc/my.cnf is not on the first place in that Honza> output. Can somebody give me a hint? Am I just blind? I did check the mysqld version that comes with OpenSuse 12.3 and this gives: Default options are read from the following files in the given order: /etc/mysql/my.cnf /etc/my.cnf ~/.my.cnf This packet is named: mariadb-5.5.29-1.1.1.x86_64 and built by http://bugs.opensuse.org What is the version name of the libexec/mysqld that you got and who has built it? Can you get the source of the package ? Hi Monty, thanks for your explanation so far.. It's happening on all fedora packages I've tested, currently mariadb-5.5.31-4.fc19.src.rpm But when trying to build from downloaded tarball with various options I've found something interesting. When using "-DINSTALL_LAYOUT=RPM" in the cmake call, then the order is /etc/mysql/my.cnf /etc/my.cnf ~/.my.cnf but when *not* using "-DINSTALL_LAYOUT=RPM", then the order is /etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf I haven't found yet why is this happening, haven't spotted any significant #IF macro or anything what could cause this.. Maybe you have an idea? So I've investigated a bit and found the reason and possible patch. For more info see the bug report: https://mariadb.atlassian.net/browse/MDEV-4927 Cheers, Honza ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
[Maria-developers] Empty directory in mariadb's datadir is not handled correctly
Hi guys, quite tricky problem came up after a directory has been created by something else than mysqld in the datadir. Suppose we use datadir=/var/lib/mysql. When we create any file in that directory by hand (or some program does it, which is not just imagination, it really happens), e.g. /var/lib/mysql/.local, MariaDB (Oracle's MySQL will behave the same probably) server thinks this directory is a database, which is wrong. Then we get some weird messages and outputs: # mysqlshow ++ | Databases | ++ | information_schema | | #mysql50#.local| | mysql | | performance_schema | | test | ++ # mysqlcheck -A mysqlcheck: Got error: 1102: Incorrect database name '#mysql50#.local' when selecting the database I believe this is not how the things should work. I'm not sure, but I'd expect there is still some information about existing databases in the information_schema table. So IMHO the server/tool should always fetch such info in addition to pure testing if the database directory exists. Or is such testing simply impossible? Regards, Honza ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
[Maria-developers] libmysqlclient.so and Fedora-specific symbol versioning
Hi guys, I'm writing this as a maintainer of MariaDB package in Fedora and RHEL. I've got some complaints about libmysqlclient symbols versioning in Fedora and future RHEL-7: https://bugzilla.redhat.com/show_bug.cgi?id=1045013 Simply put, the issue there is that RPMs (both made by MariaDB upstream or Fedora community) uses different symbol versioning than it is used in other distributions (deb packages, binary tar balls) or by other MySQL providers (Oracle, Percona). Fedora does it because it used to be done that way before and it was not changed at a time upstream changed that, since Fedora started to handle symbols list on its own. MariaDB upstream adopted Fedora's behavior as a resolution of the bug: https://mariadb.atlassian.net/browse/MDEV-3923 As a result, we have different versioning only based on packaging format now, which seems to be a problem. So, I'd like to propose to sync this gap between "RPM-based packages" and "rest of the world" in the future Fedora/RHEL releases, which basically means I'd like to ask: In case Fedora 21 and RHEL-7 adopt non-versioned symbols in libmysqlclient, would MariaDB upstream be able to do the same in RPMs for these releases? There is also second difference between RPM and non-RPM builds, which is that only limited subset of symbols (those that are documented as API) is exported in the client library in Fedora RPMs. This is because we believe exporting all symbols is wrong thing. Regarding this issue, we'd like to keep the limited set of symbols in RPMs, so, the only change I'm proposing to change versioning of these symbols (as described above). Primarily, I'd like to hear what MariaDB upstream's position on that is, if the sync can happen, but any ideas will be welcome. Honza ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] libmysqlclient.so and Fedora-specific symbol versioning
On 01/08/2014 02:25 PM, Sergei Golubchik wrote: Hi, Honza! On Jan 07, Sergei Golubchik wrote: On Jan 07, Honza Horak wrote: Primarily, I'd like to hear what MariaDB upstream's position on that is, if the sync can happen, but any ideas will be welcome. I believe, Fedora's way is the correct one. Symbols that weren't changed from libmysqlclient.so.16 should have libmysqlclient_16 version, new or modified symbols should have libmysqlclient_18 version. This way old applications that only use libmysqlclient_16.* symbols will continue working just fine. What is the point of versioning if all symbols have the same version - if the version cannot be used to distinguish symbols, one can as well use no version at all. Another thought - as Fedora is the only one that did the symbol versioning in libmysqlclient correctly, it'd be a pity to revert that for compatibility with incorectly versioned libraries. I'd consider doing the following instead (one of or all of that): * report a bug to MySQL about incorrect versioning * report a bug to Debian about incorrect versioning * change the versioning to be correct and debian-compatible, by having old symbols to appear under both libmysqlclient_16 and libmysqlclient_18 version. I don't believe Debian will use Fedora-style versioning, it's an incompatible change after all. But they might want to use "correct-and-compatible" approach with symbol aliases and two versions per symbol. Sergei, thanks a lot for both your advices, I'll try that. Anyway, do you happen to know from scratch how to define two versions for one symbol in the version script (what is the syntax)? I'm quite lost right now, but maybe you have experiences with it. Honza ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] libmysqlclient.so and Fedora-specific symbol versioning
On 01/08/2014 06:10 PM, Sergei Golubchik wrote: Hi, Honza! On Jan 08, Honza Horak wrote: * change the versioning to be correct and debian-compatible, by having old symbols to appear under both libmysqlclient_16 and libmysqlclient_18 version. I don't believe Debian will use Fedora-style versioning, it's an incompatible change after all. But they might want to use "correct-and-compatible" approach with symbol aliases and two versions per symbol. Sergei, thanks a lot for both your advices, I'll try that. Anyway, do you happen to know from scratch how to define two versions for one symbol in the version script (what is the syntax)? I'm quite lost right now, but maybe you have experiences with it. I didn't try it myself. But in the ld info pages they mention that it's possible. Info pages have an example, but it uses __asm__ and .symver, not a linker script. I think one can do the same with a linker script. Our gcc/ld gurus told be we have to use __asm__ and .symver actually. Anyway, Oracle uses it already for their Fedora builds: http://bazaar.launchpad.net/~mysql/mysql-server/5.6/view/head:/packaging/rpm-fedora/mysql-5.6-libmysqlclient-symbols.patch Also, I tried to summarize what our options are in https://bugzilla.redhat.com/show_bug.cgi?id=1045013#c12 ..feel free to add your points there. Good thing is that if we start using "correct-and-compatible" approach with symbol aliases and two versions per symbol, we're not blocked by Debian approach, since adopting the same one would make things a bit better, but even non-adoption it doesn't make it much worse. Regards, Honza ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] libmysqlclient.so and Fedora-specific symbol versioning
On 01/08/2014 06:10 PM, Sergei Golubchik wrote: Hi, Honza! On Jan 08, Honza Horak wrote: * change the versioning to be correct and debian-compatible, by having old symbols to appear under both libmysqlclient_16 and libmysqlclient_18 version. I don't believe Debian will use Fedora-style versioning, it's an incompatible change after all. But they might want to use "correct-and-compatible" approach with symbol aliases and two versions per symbol. Sergei, thanks a lot for both your advices, I'll try that. Anyway, do you happen to know from scratch how to define two versions for one symbol in the version script (what is the syntax)? I'm quite lost right now, but maybe you have experiences with it. I didn't try it myself. But in the ld info pages they mention that it's possible. Info pages have an example, but it uses __asm__ and .symver, not a linker script. I think one can do the same with a linker script. I've created a bug report with a patch that we're going to use in RHEL-7 probably. If anybody has some points/ideas for improvement, please, comment. https://mariadb.atlassian.net/browse/MDEV-5529 Honza ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
[Maria-developers] MariaDB plugin interface and embedded library compatibility
Hi guys, I'm not able to find any information about compatibility assurance of server side -- i.e plugin interface and libmysqld.so library. I expect both should have stable API at least for one minor version across bugfix releases, but I don't believe that libmysqld.so is able to preserve ABI compatibility, since the set of exported symbols there is really huge. Can you, please, provide some simple statement (ideally as an article) what is your best afford and if we can expect API/ABI of plugin/libmysqld.so interfaces? Thanks and regards, Honza ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] MariaDB plugin interface and embedded library compatibility
Thanks for your quick answers, guys, very appreciated. Regards, Honza On 01/21/2014 03:31 PM, Michael Widenius wrote: Hi! "Honza" == Honza Horak writes: Honza> Hi guys, Honza> I'm not able to find any information about compatibility assurance of Honza> server side -- i.e plugin interface and libmysqld.so library. I expect Honza> both should have stable API at least for one minor version across bugfix Honza> releases, but I don't believe that libmysqld.so is able to preserve ABI Honza> compatibility, since the set of exported symbols there is really huge. Honza> Can you, please, provide some simple statement (ideally as an article) Honza> what is your best afford and if we can expect API/ABI of Honza> plugin/libmysqld.so interfaces? A lot of the symbols in libmysqld.so comes from the internals of MariaDB and these may change from release to release. What is not changing, except between major releases, is the structures and calls to the libmysqlclient interface. In other words, if you are using libmysqld.so as a standalone database using the client interface, things are not usually changing between minor releases. If you are using internal structures in libmysqld, like THD, then you have to recompile your code for each releases. I have now adde the above in an kb article at: https://mariadb.com/kb/en/embedded-mariadb-interface/ Regards, Monty ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
[Maria-developers] Vision for next 10.x minor releases
Hi guys, first, congratulations for the 10.0 release, well done! Even though it can look insane, I'm already wondering about next minor releases ;) Especially if you have already some idea about 10.1 and later. Specifically, I'm wondering if these releases will still be somehow tight to MySQL's release cycle (say 10.1 will be somehow following 5.7) or if you plan totally independent release schedule like slower/faster the release cadence? In other words, since MySQL changed only minor version and MariaDB bumped the major (we all know the reason), I'm wondering if something changed in thinking about major/minor versioning -- like if the difference between 10.0 and 10.1 will still be considered the same like between say 5.3 and 5.5. I don't expect you can give us any dates, but some expectations, if 10.1 can be expected in months or rather years? If that was already discussed somewhere, please, just point me to the correct place. Thanks, Honza ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Vision for next 10.x minor releases
On 04/07/2014 08:36 PM, Sergei Golubchik wrote: Hi, Honza! On Apr 07, Honza Horak wrote: Hi guys, first, congratulations for the 10.0 release, well done! Thanks! Even though it can look insane, I'm already wondering about next minor releases ;) Especially if you have already some idea about 10.1 and later. I believe, by the "next minor release" you mean 10.1, not 10.0.11. Exactly, I had 10.1 on my mind. Specifically, I'm wondering if these releases will still be somehow tight to MySQL's release cycle (say 10.1 will be somehow following 5.7) or if you plan totally independent release schedule like slower/faster the release cadence? Independent. I don't expect you can give us any dates, but some expectations, if 10.1 can be expected in months or rather years? The first 10.1.0-alpha can be expected in a few months. But it is unlikely that a 10.1-GA release will come out in less than a year. Great, thank you very much for this answer! Regards, Honza ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
[Maria-developers] Allow to turn off max_connect_errors
Hi guys, there are apparently some tools out there [1], that check if the server is up quite often, while not closing the connection properly. It eventually ends in 'many connection errors', because max_connect_errors is always limited now. I understand that this way of checking may be wrong, but there may be scenarios where we do not want to check for `max_connect_errors` at all. So, would it be acceptable for mariadb to change behaviour of max_connect_errors option, so that it accepts also 0 as a possible value, which would mean 'do not check connect errors at all'? I'm bringing the idea here first, but will submit a report and possibly patch if it does not seem to be undesired behaviour. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1104957 TIA and regards, Honza ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Allow to turn off max_connect_errors
On 06/12/2014 05:08 PM, Sergei Golubchik wrote: Hi, Honza! there are apparently some tools out there [1], that check if the server is up quite often, while not closing the connection properly. It eventually ends in 'many connection errors', because max_connect_errors is always limited now. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1104957 What's the status of that? Was any workaround (skip-name-resolve, max_connect_errors=4294967295 or FLUSH HOSTS, which can be run periodically with CREATE EVENT) considered good enough? I see that the bug is closed as NOTABUG. Guys who reported this started using skip-name-resolve=1, but it does more than necessary, so it is still considered a work-around and it still seems to be a good idea to add some feature that would disable only max_connect_errors. Honza ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
[Maria-developers] mariadb native client -- how to call RPMs?
Hi, in Fedora, we're about to package mariadb-native-client, which we'd like to utilize in Fedora as much as possible since using this piece of software we can break the dependency on whole mariadb server package and thus make the base system more compact. However, since mariadb.org does not provide RPMs yet, I'm wondering what would be the best name for such RPM package. The tar ball is called mariadb_client.tar.gz but the project is called mariadb-native-client on launchpad, which I like more btw. because it differs more from mariadb-client package (which is actually a subpackage of mariadb). So, is mariadb-native-client a good choice or is there a better one? Cheers, Honza ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] mariadb native client -- how to call RPMs?
On 09/04/2014 05:17 PM, Sergei Golubchik wrote: Hi, Honza! On Sep 03, Honza Horak wrote: in Fedora, we're about to package mariadb-native-client, which we'd like to utilize in Fedora as much as possible since using this piece of software we can break the dependency on whole mariadb server package and thus make the base system more compact. Hm, does libmysqlclient depend on the server package? Why would it? Not really, I'm not considering the resulting binary RPMs, but components of the distro including sources as a whole. What I meant was that if anybody needs to e.g. build a mariadb connector for ruby, he needs to pull libmysqlclient and this one is built from 40MB large srpm of mariadb, which brings unnecessary complexity (rebases of whole server are more frequent, require more work to package them etc.) Having just tiny libmysqlclient would be much better for smaller core system. However, since mariadb.org does not provide RPMs yet, I'm wondering what would be the best name for such RPM package. The tar ball is called mariadb_client.tar.gz but the project is called mariadb-native-client on launchpad, which I like more btw. because it differs more from mariadb-client package (which is actually a subpackage of mariadb). In our packages mariadb-client is the package with the tools, the library is in mariadb-shared. And the project is called mariadb/connector-c on github, so don't put too much weight on the project name. Right, we only want to follow Fedora guidelines that tell us to pay attention for picking up a proper name. So, is mariadb-native-client a good choice or is there a better one? How are packages with shared libraries usually named on Fedora? Well, there is not only one pattern, but most common is either a subpackage with shared libraries called foo-libs or a pure library package called libfoo. In our packaging we alias MariaDB-shared to mariadb-libs, so, I suppose xxx-libs is what you usually use. Then I'd suggest mariadb-native-libs or mariadb-lgpl-libs or something like that. Personally, I do not like the license name in the name very much, but mariadb-native-libs or mariadb-connector-c sound fine. Thanks for the ideas. Honza ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
[Maria-developers] Not possible to use FIFO file as a general_log file
This is just a re-sending the issue reported already at https://mariadb.atlassian.net/browse/MDEV-6870 to make it more visible, since there is no respond yet. There was an issue [1] in mysql and mariadb prior to 5.5.40 if socket or fifo files were used as general_log and slow query log files. That issue was fixed by a commit in [2], so currently it is not possible to use other than regular files as log files. I'd like to bring this issue to attention of mariadb developers as well, since our customer is asking for specifically this functionality – to be able to use FIFO file as general_log file. Is it really unacceptable? [1] http://bugs.mysql.com/bug.php?id=67088 [2] http://bazaar.launchpad.net/~mysql/mysql-server/5.5/revision/4688 ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
[Maria-developers] any plans to bump soname for libmysqlclient.so?
Hi, mysql 5.7 bumped soname of the libmysqlclient.so. Are there any plans to do something like that in mariadb's libmysqlclient.so? I'm also wondering whether there are any particular plans to keep compatibility of the client library (libmysqlclient.so) between MariaDB and MySQL in the future. Honza ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
