← Back to team overview

maria-developers team mailing list archive

Re: [Bug 544173] [NEW] Server crash for multi-engine transaction with binlog disabled

 

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




References