MySQL Bugs: #45379: MySQL shouldn't "guess" at the variable names

Bug #45379	MySQL shouldn't "guess" at the variable names
Submitted:	8 Jun 2009 18:00	Modified:	5 Aug 2015 8:22
Reporter:	Sheeri Cabral (Candidate Quality Contributor)	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Server: Options	Severity:	S4 (Feature request)
Version:	5.1.31, 5.0, 5.1, 6.0 bzr	OS:	Linux
Assigned to:		CPU Architecture:	Any
Tags:	GROUP, group_concat_max_len

Description:
On MySQL 5.1.31, with a my.cnf that contains no value for group_concat_max_len, the following warning appears in the MySQL error log when mysqld is restarted:

[Warning] option 'group_concat_max_len': unsigned value 0 adjusted to 4

There is the following variable:

group=mysql

And when that is taken out, the warning doesn't appear.

This means that the value of group_concat_max_len is set to the minimum value (4) when group, an unrelated variable, is set.

How to repeat:
Start up a generic mysqld instance (5.1.31) with no config file

create a config file and add

group=mysql

to the mysqld directive.  restart, and see the problem.

Suggested fix:
MySQL shouldn't "guess" at the variable names -- either it is the right syntax or not.  I suppose this comes about because of variables with names like "sort_buffer" when the variable in mysqld is "sort_buffer_size".

I suggest either honoring the "group" variable or giving an error that it is not a known variable.

Thank you for the report.

Verified as described.

are you sure this is a bug and not just a confusion.  options have always been
recognised by their shortest non-ambiguous versions.  "group=mysql" is actually
seen as "group_concat_max_len=mysql".

since 'mysql' is not a number, it's converted to 0. since 0 is invalid value for group_concat_max_len, it's set to the minimum value of 4.

The problem is customer placed "group=mysql" in [mysqld] section instead of [mysqld_safe].  all this is documented, somewhere in the manual when I checked.

Shane,

thank you for the hint. You are right - according to http://dev.mysql.com/doc/refman/5.1/en/program-options.html this is not a bug:

An option can be specified by writing it in full or as any unambiguous prefix. For example, the --compress option can be given to mysqldump as --compr

I don't think "group" is unambiguous in this case.

Saw this too.  Group should not be short for group_concat_max_len.  That's a big risk for potential data corruption, as was just seen with aclient.

This is just wrong.
The fact that it's "logical" in the code doesn't make it any more sensible from the outside.

The config parser should not take shorthand, it should only accept full option names.
I realise this might cause issues with people who have been slack, but I have personally not actually seen shorthand being used - people always put in the full option name anyway. Chances are nobody is (consciously) aware of the shorthand ability anyway. And thank goodness for that. Let's get rid of it!
Thanks

Thank you for the feedback.

If 3 different people ask about removing this feature reclassifying report to feature request with new synopsis.

+1 on resolving this feature request.

+1 on resolving this feature request.

+1 for a fix, this is wrong, wrong, wrong. There is no way config files should make, cause, inflict soft changes for options, shorthand be gone.

5.7 fixes this because you can no longer specify short names for variables.

2015-04-15T05:04:56.205775Z 0 [ERROR] unknown variable 'group=mysql'
2015-04-15T05:04:56.206775Z 0 [ERROR] Aborting

Okay to close this FR ?

Can this be backported? We just ran into this issue with a mysqld 5.6.25 installation.

Closing as a duplicate of http://dev.mysql.com/worklog/task/?id=6978.
Unfortunately back-porting this incompatible change to a stable release would cause too much disturbance to existing installations.