maria-discuss team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

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_improvements_for_io-bound_highly-concurrent_workloads.html#relative-thread-scheduling-priorities-for-xtradb.
> >> 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