Know your my.cnf groups, part II

Ronald Bradford’s recent warning to be sure to know your my.cnf sections reminded me of a similar issue that I ran into last summer, where putting the “group” option in both the [mysqld_safe] and [mysqld] directives resulted in a mostly silent problem.

I started noticing this in MySQL 5.1 and it affected both the official MySQL binary and the Percona binary. In trying to be conscientious, I had the following set:

[mysqld_safe]
user=mysql
group=mysql

[mysqld]
user=mysql
group=mysql

However, when the MySQL server started up, the error log showed

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

This was obviously a problem, but I only started noticing it during MySQL restarts, which was mostly during upgrades to MySQL 5.1. I tracked it down and realized that when I removed the “group” option from the [mysqld] directive, the warning did not come up.

The problem is that [safe_mysqld] sees “group” as the “group” option, but [mysqld] does not know about the “group” option. The MySQL server allows the shortest unique identifier of an option to *be* that option. Thus, “group” is an acceptable abbreviation for “group_concat_max_len”.

So mysqld was taking:
group=mysql

and translating it to:
group_concat_max_len=mysql

but “mysql” is a string, not a number, so MySQL tried to be helpful by converting to a number….so it was as if I stated:
group_concat_max_len=0

I filed a bug for this back in June:
http://bugs.mysql.com/bug.php?id=45379. The response was “If 3 different people ask about removing this feature reclassifying report to feature request with new synopsis.”

So, a second moral: make a bug report if you want things to get changed, and if you see a bug report for a problem you’re encountering, make sure to add your voice so that MySQL understands that an issue is indeed serious.

Ronald Bradford’s recent warning to be sure to know your my.cnf sections reminded me of a similar issue that I ran into last summer, where putting the “group” option in both the [mysqld_safe] and [mysqld] directives resulted in a mostly silent problem.

I started noticing this in MySQL 5.1 and it affected both the official MySQL binary and the Percona binary. In trying to be conscientious, I had the following set:

[mysqld_safe]
user=mysql
group=mysql

[mysqld]
user=mysql
group=mysql

However, when the MySQL server started up, the error log showed

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

This was obviously a problem, but I only started noticing it during MySQL restarts, which was mostly during upgrades to MySQL 5.1. I tracked it down and realized that when I removed the “group” option from the [mysqld] directive, the warning did not come up.

The problem is that [safe_mysqld] sees “group” as the “group” option, but [mysqld] does not know about the “group” option. The MySQL server allows the shortest unique identifier of an option to *be* that option. Thus, “group” is an acceptable abbreviation for “group_concat_max_len”.

So mysqld was taking:
group=mysql

and translating it to:
group_concat_max_len=mysql

but “mysql” is a string, not a number, so MySQL tried to be helpful by converting to a number….so it was as if I stated:
group_concat_max_len=0

I filed a bug for this back in June:
http://bugs.mysql.com/bug.php?id=45379. The response was “If 3 different people ask about removing this feature reclassifying report to feature request with new synopsis.”

So, a second moral: make a bug report if you want things to get changed, and if you see a bug report for a problem you’re encountering, make sure to add your voice so that MySQL understands that an issue is indeed serious.