Bug #39462 No deprecation when removing Hash table size, used cells from INNODB STATUS outp
Submitted: 15 Sep 2008 23:09 Modified: 16 Oct 2008 9:33
Reporter: James Day
Status: Not a Bug
Category:Server: InnoDB Severity:S3 (Non-critical)
Version:5.1.28 OS:Any
Assigned to: Vasil Dimov Target Version:
Tags: regression
Triage: Triaged: D3 (Medium) / R1 (None/Negligible) / E1 (None/Negligible)

[15 Sep 2008 23:09] James Day 
Description:
Bug #36941 removed "Hash table size 3112859, used cells 1050451" output from SHOW ENGINE
INNODB STATUS output without following the feature deprecation process. This can break
applications that parse the output.

How to repeat:
Compare SHOW ENGINE INNODB STATUS output and notice missing output.

Suggested fix:
Provide the output with zero values and document that they will be zero unless the server
is compiled with UNIV_DEBUG.

And/or follow deprecton process. I don't think it's necessary, zero values will suffice.
[20 Sep 2008 15:20] Darren Oldag 
running the 2.0 Enterprise Monitor agent against 5.1.28 reveals these warnings:

2008-09-20 16:15:49: (critical) job_collect_mysql.c.460: executing the regex for innodb
pattern "Total number of lock structs in row lock hash table (\d+)" (57) failed: -1
2008-09-20 16:15:49: (critical) job_collect_mysql.c.460: executing the regex for innodb
pattern "Hash table size (\d+), used cells \d+, node heap has \d+ buffer.s." (66) failed:
-1
2008-09-20 16:15:49: (critical) job_collect_mysql.c.460: executing the regex for innodb
pattern "Hash table size \d+, used cells (\d+), node heap has \d+ buffer.s." (66) failed:
-1
2008-09-20 16:15:49: (critical) job_collect_mysql.c.460: executing the regex for innodb
pattern "Hash table size \d+, used cells \d+, node heap has (\d+) buffer.s." (66) failed:
-1
[1 Oct 2008 10:38] Vasil Dimov 
It has not been stated that the output will never change and as far as I know the output
is not documented at all.

Thus any application that is not flexible enough to parse output with "missing" lines is
broken anyway. There could be applications that do not expect zero values either (if they
try to divide by the value, for example) which could "be broken" by emitting zero values
too.

Innobase discussed whether to print zero or to remove the line and decided that zero
values could be more confusing and/or misleading than "missing" lines.

We could easily restore the lines with zero values but I think the current behavior is
just fine and this report should be set to "Not a bug".

Applications that parse the output should be more flexible, the output can change in the
future too, it is not guaranteed to stay like this forever.

Pending discussion at Innobase...
[1 Oct 2008 15:32] Heikki Tuuri 
All,

I agree with Vasil. The SHOW INNODB STATUS output has changed many times in minor
versions of mysqld. The parser of the output has to be prepared to that.

Regards,

Heikki
[16 Oct 2008 9:33] Vasil Dimov 
Setting to "Not a Bug", there was no objection to my comment from Oct 1.