----- Original Message -----
> From: "Rik Wasmus" <rik@stripped>
> OK, but that would mean that the answer to the question:
> "I may be wrong here, but I tend to interpret this as
> '140054029002496' is trying to get an exclusive lock on 0x78733f8, on which it
> already has
> an exclusive lock, and hence is deadlocked in some manner" is 'no there
> is another query' (i.e.: it isn't locked on mistakingly acquiring a lock
> it already has) rather then 'that seems likely' :)
Ah, misread that. Yes, the former behaviour seems more like a bug; which is not entirely
impossible of course.
> And in my case, the server became unusable (kept running into
> semaphore locks at 769 seconds before a kill & start was given). Query timeouts
> crashes I can live with, an unresponsive server I cannot...
Which is what kind of mystifies me - it should detect deadlocks as soon as they happen.
> OK, let's hope I never get to show that output (i.e: that the problem
> doesn't reoccur). Since the server has been restarted since-start counters
> will probably be pretty useless.
Yups. A trending database (munin, cacti or something) may or may not offer much hindsight
in this case (mostly a matter of luck at when it last checked); but it's definitely
something useful to have at hand for plenty of other purposes.
> Yup, right there it did, And that's the way I like it: kill the/a
> query, which issues an error somewhere else we know if and how to handle in some
> application, rather then letting a database server with a light load
> grind to a halt.
> My main problem at hand is why the server did nothing but seize up
> gracelessly, rather then either dying (a last resort, but something
> we have failovers for) or killing queries (which we can handle).
Uhuh. You may want to take this to the mysql-dev mailinglist, the good people there might
have a bit more insight about the error runes you posted.
Bier met grenadyn
Is als mosterd by den wyn
Sy die't drinkt, is eene kwezel
Hy die't drinkt, is ras een ezel