Hi Sergei,
Thanks for the info. That was a problem that caused me a lot of
trouble until we finally made recovery asynchronous.
The unlock hack can probably be removed altogether now. I have
checked, and it has been removed in PBXT 1.1. Since recovery is
asynchronous, waiting for LOCK_plugin to be released is no longer a
problem.
Now that you have fixed the problem in MariaDB, we just have to wait
for it to be done in MySQL, and then we could consider making recovery
synchronous again.
This would make it possible to prevent startup of the server if
recovery fails. But I am not so sure this is an advantage.
Best regards,
Paul
On Mar 1, 2010, at 12:34 AM, Sergei Golubchik wrote:
Hi,
Paul, I was backporting libservices to MariaDB, and with a related
test case found a bug in MariaDB - mutexes were locked in the wrong
order. I've fixed that some time ago in mysql-next, so I took the fix
from there - the fix was to not lock LOCK_plugin over the plugin
initialization code. After that pbxt started crashing here:
#if MYSQL_VERSION_ID < 60014
myxt_mutex_unlock(&LOCK_plugin);
#endif
as it was unlocking the mutex that was not locked.
For now I simply commented out your locking/unlocking of this mutex in
the MariaDB tree. But probably you may want a better fix, may be even
your FREERER-HANG problem will go away too ?
I've submitted http://bugs.mysql.com/51591 hopefully it will be
fixed in
MySQL too.
Regards,
Sergei
--
Paul McCullagh
PrimeBase Technologies
www.primebase.org
www.blobstreaming.org
pbxt.blogspot.com
_______________________________________________
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
