Hi, Laurynas! On Feb 10, Laurynas Biveinis wrote:
Sergei -
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.
Pushing down -march=i686 to xtradb dir only would work around this, wouldn't it?
Yes. I wasn't quite sure whether it's a good idea to build different parts of the server with different -mtune settings. But ok, I'll try that.
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?
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 :)
Yes, I mean the different behavior. It's OK for us because the behavior is correct on all the platforms we support, but it wouldn't be OK on some of the platforms you support, would it?
I believe it's ok anyway. MySQL always used to have platform-specific features, like thread priorities, connections that use shared memory, and so on. Regards, Sergei