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
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]

Reply via email to