Hi, Paul! On Mar 31, Paul McCullagh wrote: > On Mar 25, 2010, at 10:24 PM, Sergei Golubchik wrote: >> Hi, MARK! >> >> On Mar 25, MARK CALLAGHAN wrote: >>> On Wed, Mar 24, 2010 at 5:28 PM, Arjen Lentz <ar...@openquery.com> wrote: >>>> This test is as important as the above crash, because multi-engine >>>> transactions are something people will be using and thus relying on >>>> correctly working >>> >>> I won't use this. We have enough problems when limited to one >>> storage engine. All of those should be fixed first. If I want to use >>> PBXT (and I do) then I will stop using InnoDB (and I might). >>> >>> When will we have cross-engine deadlock detection? >> >> When storage engines will start using a central server-wide deadlock >> detector (that exists). > > Interesting... I did not know that this existed. > > Any idea of the performance? As we have seen from Mark's blog, it can > be critical.
I've written it for Maria engine, but as a server global (not Maria engine specific) detector detector. It could be used by other server components. Because it's not really used yet (besides stress unit tests), I couldn't compare the performance with anything or come up with any meaningful performance numbers. It has no global mutexes, every node of a global wait-for graph has an individual lock, so any number of threads may modify different parts of the wait-for graph without waiting for each other. It's not a lock manager, but only a deadlock detector - in a sense it's "wait manager", an engine (or any other server subsystem) only needs to use it before starting to wait on anything, in a simplified view it's a replacement for pthread_cond_wait. Regards, Sergei _______________________________________________ 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