Hi Sergei, On Mar 3, 2010, at 10:06 AM, Sergei Golubchik wrote:

Hi, Paul!

On Mar 01, Paul McCullagh wrote:

...

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.

Okay. So, what do you prefer me to do now, in Maria-5.2 ? Comment out the mutex lock/unlock ? Remove the whole #if ? Use PBXT 1.1 ?

You can just remove the #if, but keep the comments. I will do this for 1.0 as well.

...

This would make it possible to prevent startup of the server if recovery fails. But I am not so sure this is an advantage.

It's not all black and white, all synchronous or all asynchronous. Usually a user would like to see the database to be accessible as soon as possible, that is as much of the recovery should be asynchronous as possible, but without compromising data integrity.

In ARIES, for example, Undo phase can be done asynchronously, allowing users to connect and see the data even when recovery is still in progress.

Regards, Sergei

-- Paul McCullagh PrimeBase Technologies www.primebase.org www.blobstreaming.org pbxt.blogspot.com