maria-developers team mailing list archive

[Paul McCullagh <paul.mccullagh@xxxxxxxxxxxxx>]

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