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 <arjen@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