[Maria-developers] LOCK_plugin in pbxt_init()
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
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
On Mon, 1 Mar 2010 10:27:44 +0100, Paul McCullagh <paul.mccullagh@primebase.org> wrote:
This would make it possible to prevent startup of the server if recovery fails. But I am not so sure this is an advantage.
I've always been in 2 minds about this.... my guess is that a lot of code for "is this server alive" at most: a) connects to socket b) runs "SELECT 1;" and none of them actually check the storage engine you're using is okay. -- Stewart Smith
This is a good point! :) Speaks for killing the server if recover fails. On Mar 3, 2010, at 1:39 AM, Stewart Smith wrote:
On Mon, 1 Mar 2010 10:27:44 +0100, Paul McCullagh <paul.mccullagh@primebase.org
wrote: This would make it possible to prevent startup of the server if recovery fails. But I am not so sure this is an advantage.
I've always been in 2 minds about this....
my guess is that a lot of code for "is this server alive" at most: a) connects to socket b) runs "SELECT 1;"
and none of them actually check the storage engine you're using is okay.
-- Stewart Smith
-- Paul McCullagh PrimeBase Technologies www.primebase.org www.blobstreaming.org pbxt.blogspot.com
participants (3)
-
Paul McCullagh -
Sergei Golubchik -
Stewart Smith