Hi, Laurynas! On Feb 07, Laurynas Biveinis wrote:
Sergei, Colin, MariaDB -
"XtraDB storage engine was upgraded to the 5.6 version. Now one can use XtraDB with MariaDB 10.0. Unlike MariaDB 5.5, in 10.0 XtraDB is not the default engine, the default is InnoDB, and XtraDB is available as a dynamic plugin"
XtraDB simply does not compile on all our builders - Percona has introduced patches that use CPU atomic ops and didn't implement a fallback for setups where they are not available (like all the rest of the code does, including InnoDB).
Have we reported bugs upstream?
https://bugs.launchpad.net/bugs/1276963
Do we plan on fixing this ourselves if upstream doesn't?
Not at the moment - that code is quite complex.
In the bug report you mention RHEL 5 with GCC 4.1.2 (presumably on 32 bits). This is one of our supported platforms too, and we solve this by adding -march=i686 which makes the necessary builtins available. Would that work for you?
That kind of worked. XtraDB compiled. But query_response_time failed with "unable to find a register to spill in class 'GENERAL_REGS'". Still better than before. In the worst case, I'll enable XtraDB and disable query_response_time plugin.
We have another platform-specific addition: thread-local storage implemented by __thread GCC keyword, which is GNU specific. This is
Yes, I've noticed. It caused lots of valgrind warnings because __thread implementation uses __tls_get_addr() in glibc and that allocated memory which valgrind didn't see being freed. I've added a suppression for it.
used to implement the relative XtraDB thread priorities: http://www.percona.com/doc/percona-server/5.6/performance/xtradb_performance.... On non-Linux plaftorms the feature should compile but should be silently disabled, that is, setting innodb_sched_priority_* options are no-ops. How big is this an issue for you?
Besides this valgrind warning there were no issues so far. Or do you mean a different behavior of innodb_sched_priority_* options? I think it's ok for us, if it's ok for you :) Regards, Sergei