From: Baron Schwartz (baronxaprb.com)
Date: Mon Jul 30 2007 - 07:48:16 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Mark Leith wrote:
> Baron Schwartz wrote:
>> Mark Leith wrote:
>>> Baron Schwartz wrote:
>>>> I stand corrected. I don't know why I didn't think of this!
>>>>
>>>> So you guys had to go the route of parsing InnoDB status too, huh?
>>>> Fun, isn't it!
>>>
>>> Indeed, it is a rather interesting thing to do ;) Made even better
>>> when it is limited to 64K and truncated with large transactions!
>>
>> Or a big deadlock with tons of tuples. I have submitted a feature
>> request to remove the list of locks held, but I don't know how high a
>> priority it's given. It's useless for non-developers, though Heikki
>> told me he uses it every day. I wouldn't think it'd be hard to define
>> a compile-time option whether to include all the tuples locked, so
>> Heikki and Marko could see it but spare the rest of us :) Of course
>> seeing just the first part of that output, which shows what kind of
>> lock was held on which index, is very useful for non-InnoDB-developers
>> too.
>
> Have you filed a feature request on this? I would agree that the list of
> locks is certainly not of use to the average DBA, so removing this by
> default would be a good idea.

Yes, it's here: http://bugs.mysql.com/bug.php?id=29126

I actually combined two bug requests in one, now that I think about it. Maybe this
wasn't a good idea. Maybe "trim down deadlock info" and "add lock info to normal
output" should have been separated.

>> Yep. But there's always that legacy support you have to keep around!
>
> Exactly! ;)
>
> If 'you' have parsed the output in a sane manner, many tools should be
> unaffected, however, we can not rely on that, and changing innodb status
> could break a lot of scripts already made out there ;) This is why we
> have to be very careful and considered in making these kinds of changes.
> Of course, the burden is also on the InnoDB developers to do this.

I don't see how this change could be made without breaking non-sane scripts, though.
This might have to be an incompatible change for those scripts that rely on seeing the
list of tuples. For my part, as far as I know innotop's parser should be able to
handle it as-is, and shouldn't even care about the order in which the sections are
placed in the output. But I'd have to make a test case to prove that. Regardless,
support for Google's patches is on the 1.6 roadmap for innotop, so there'll be a chance
for me to see -- but not right now, I'm too busy with other things!

Baron

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]