maria-developers team mailing list archive

[Paul McCullagh <paul.mccullagh@xxxxxxxxxxxxx>]

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