Re: [arch-dev-public] [Draft] MariaDB 10.0 enters [extra]
On Sat, 17 May 2014 22:57:46 +1000 Allan McRae al...@archlinux.org wrote: On 17/05/14 22:40, Bartłomiej Piotrowski wrote: It's temporarily built using Clang, mainly because new gcc snapshot hasn't fixed segfaults for everyone. Please file bug reports for breakages caused by the gcc update. I can not track/report/fix bugs that are not brought to my attention. Allan Apparently all are gone with -fno-delete-null-pointer-checks. I can try to write a small example during next week. If no one has any objections, I'll move the packages and publish this draft tomorrow. -- Bartłomiej Piotrowski http://bpiotrowski.pl/ signature.asc Description: PGP signature
Re: [arch-dev-public] [Draft] MariaDB 10.0 enters [extra]
Am 17.05.2014 14:40, schrieb Bartłomiej Piotrowski: Hi guys, New MariaDB is sitting in [testing] for a while now. It's temporarily built using Clang, mainly because new gcc snapshot hasn't fixed segfaults for everyone. I want to resolve it before moving anything, but in the meantime I wrote an announcement draft. Title: MariaDB 10.0 enters [extra] Content: A new major release of MariaDB will be moved to [extra] soon. The change in versioning scheme has been made to clearly distinguish provided functionality from MySQL 5.6. From now on, it won't be possible to easily move between various MySQL implementations provided in the official repositories. I guess the client library remains compatible or do we need to recompile packages? ATM we also provide MySQL 5.6 by packaging the percona fork. It provides the mariadb version as well, is that still sensible with 10 starting to be incompatible with mysql? Due to major changes in MariaDB 10.0, it is recommended (although not necessary) to dump the tables before upgrading and reloading the dump file afterwards. After upgrading to the new version don't forget to restart `mysqld.service` and run `mysql_upgrade` to check the databases for possible errors. Why is it recommend to reload from a dump? Some more details would be good, as this is not easily doable (without a longer downtime) for users with large databases. Additionally TokuDB storage engine has been disabled because of repeating build failures. I'm sorry for any inconvenience caused. Well, we provide this with our current 5.5 packages? What happens to those who use this? Instead of the I am sorry.. part, better link to the upstream bug report. For detailed information on changes and upgrade steps, please refer to [MariaDB Knowledge Base](https://mariadb.com/kb/en/what-is-mariadb-100/) and [MySQL Reference Manual](https://dev.mysql.com/doc/refman/5.6/en/upgrading.html). In addition to this, is the gcc 4.9 issue reported somewhere and the workaround confirmed? This bug seems to destroy the db files, so we better be sure. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com
Re: [arch-dev-public] [Draft] MariaDB 10.0 enters [extra]
On Sun, 25 May 2014 17:48:31 +0200 Pierre Schmitz pie...@archlinux.de wrote: I guess the client library remains compatible or do we need to recompile packages? ATM we also provide MySQL 5.6 by packaging the percona fork. It provides the mariadb version as well, is that still sensible with 10 starting to be incompatible with mysql? Good point. The client library is still compatible, client tools are not[1]. Percona probably should explicitly depend on percona-server-clients=$pkgver, so should MariaDB. Why is it recommend to reload from a dump? Some more details would be good, as this is not easily doable (without a longer downtime) for users with large databases. It is a common procedure encouraged by MySQL upstream, not mandatory by any means. Well, we provide this with our current 5.5 packages? What happens to those who use this? Instead of the I am sorry.. part, better link to the upstream bug report. Currently it is available in the [extra] package. TokuDB upstream is not as responsive as I would expect and I'm still waiting for the fix for build failure I reported almost 6 months ago. I don't mind reporting one more, I just don't think it will get fixed in a reasonable time. In addition to this, is the gcc 4.9 issue reported somewhere and the workaround confirmed? This bug seems to destroy the db files, so we better be sure. If MariaDB is built using gcc = 4.9-20140507 without this flag, it still crashes but doesn't loss any data. I have reported the problem and possible workaround on the MariaDB bug tracker. [1] https://bugs.archlinux.org/task/40041 -- Bartłomiej Piotrowski http://bpiotrowski.pl/ signature.asc Description: PGP signature
Re: [arch-dev-public] [Draft] MariaDB 10.0 enters [extra]
On 25/05/14 10:33 AM, Bartłomiej Piotrowski wrote: On Sat, 17 May 2014 22:57:46 +1000 Allan McRae al...@archlinux.org wrote: On 17/05/14 22:40, Bartłomiej Piotrowski wrote: It's temporarily built using Clang, mainly because new gcc snapshot hasn't fixed segfaults for everyone. Please file bug reports for breakages caused by the gcc update. I can not track/report/fix bugs that are not brought to my attention. Allan Apparently all are gone with -fno-delete-null-pointer-checks. I can try to write a small example during next week. If no one has any objections, I'll move the packages and publish this draft tomorrow. If that solves it, it's quite possible that the code has undefined behaviour rather than this being a GCC bug. One possibility is a race condition where a pointer's value is read/written concurrently without atomics (maybe helgrind can find something?). signature.asc Description: OpenPGP digital signature
[arch-dev-public] [Draft] MariaDB 10.0 enters [extra]
Hi guys, New MariaDB is sitting in [testing] for a while now. It's temporarily built using Clang, mainly because new gcc snapshot hasn't fixed segfaults for everyone. I want to resolve it before moving anything, but in the meantime I wrote an announcement draft. Title: MariaDB 10.0 enters [extra] Content: A new major release of MariaDB will be moved to [extra] soon. The change in versioning scheme has been made to clearly distinguish provided functionality from MySQL 5.6. From now on, it won't be possible to easily move between various MySQL implementations provided in the official repositories. Due to major changes in MariaDB 10.0, it is recommended (although not necessary) to dump the tables before upgrading and reloading the dump file afterwards. After upgrading to the new version don't forget to restart `mysqld.service` and run `mysql_upgrade` to check the databases for possible errors. Additionally TokuDB storage engine has been disabled because of repeating build failures. I'm sorry for any inconvenience caused. For detailed information on changes and upgrade steps, please refer to [MariaDB Knowledge Base](https://mariadb.com/kb/en/what-is-mariadb-100/) and [MySQL Reference Manual](https://dev.mysql.com/doc/refman/5.6/en/upgrading.html). -- Bartłomiej Piotrowski http://bpiotrowski.pl/ signature.asc Description: PGP signature
Re: [arch-dev-public] [Draft] MariaDB 10.0 enters [extra]
On 17/05/14 22:40, Bartłomiej Piotrowski wrote: It's temporarily built using Clang, mainly because new gcc snapshot hasn't fixed segfaults for everyone. Please file bug reports for breakages caused by the gcc update. I can not track/report/fix bugs that are not brought to my attention. Allan
Re: [arch-dev-public] [Draft] MariaDB 10.0 enters [extra]
On 17/05/2014 14:57, Allan McRae wrote: On 17/05/14 22:40, Bartłomiej Piotrowski wrote: It's temporarily built using Clang, mainly because new gcc snapshot hasn't fixed segfaults for everyone. Please file bug reports for breakages caused by the gcc update. I can not track/report/fix bugs that are not brought to my attention. https://bugs.archlinux.org/task/40304 -- Sébastien Seblu Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A signature.asc Description: OpenPGP digital signature
