MySQL Doesn’t Always Suck; This Time it’s AMD

http://timetobleed.com/mysql-doesnt-always-suck-this-time-its-amd/

by ice799 • 17 years ago

63 12 17 years ago

briansmith2• 17 years ago

I would say MySQL's response sucked plenty. No effort was made to document the issue for end-users in the release notes. No effort was made to document a workaround that end-users could implement. No attempt was made to provide a workaround in the code; if a workaround was truly impossible as claimed, then why not implement a killswitch to prevnt MySQL from running in such a configuration?

smcdow• 17 years ago

Workaround? Are you suggesting that MySQL somehow hotpatch the kernel (which is what would be needed to fix the problem)? When was the last time you saw a userland process hotpatch a kernel? This issue belongs to the kernel hackers, not userland people. And a killswitch? Great. Then what? Go buy new hardware?

briansmith2• 17 years ago

I don't know the code. Maybe they could work around it by using a different primitive. They could change the multiprocessing technique in these configurations. They could change the RPM so that it has a dependency on the a kernel version where this bug is fixed or a dependency on the specific patch that fixes it.

I'd rather have MySQL refuse to start in a known-bad configuration than crash during runtime. Maybe I would have to buy new hardware; most likely I'd just have to patch the kernel.

Remember, MySQL is a database. For many of its applications, it is important that it doesn't crash.

vicaya• 17 years ago

Quick reference: cat /proc/cpuinfo

Your processor is buggy if it's an Opteron family 15, models 32-63 inclusive.

ice799• 17 years ago

Good call. I should have included something like this in my post. I'll update it and give you a shout-out. Thanks for commenting!

MySQL Doesn’t Always Suck; This Time it’s AMD

Related Stories