MySQL Bugs: #39462: No deprecation when removing Hash table size, used cells from INNODB STATUS outp

Bug #39462	No deprecation when removing Hash table size, used cells from INNODB STATUS outp
Submitted:	15 Sep 2008 21:09	Modified:	16 Oct 2008 7:33
Reporter:	James Day	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server: InnoDB storage engine	Severity:	S3 (Non-critical)
Version:	5.1.28	OS:	Any
Assigned to:	Vasil Dimov	CPU Architecture:	Any
Tags:	regression

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.

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

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...

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

Setting to "Not a Bug", there was no objection to my comment from Oct 1.