Bug #74037 group_concat_max_len=18446744073709547520 not accepted in my.cnf

• Submitted: 23 Sep 2014 16:02
• Modified: 2 Feb 2015 16:06
• Reporter: Leandro Morgado
• Status: Closed
• Category: MySQL Server: Options
• Severity: S2 (Serious)
• Version: 5.6.20
• OS: Linux
• CPU Architecture: Any

[23 Sep 2014 16:02] Leandro Morgado

Description:
According to the manual, the maximum value for group_concat_max_len in 64bit mysqld is 18446744073709547520. This works fine when set dynamically in the mysql> prompt. 
 http://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_group_concat_ma...

However, if the value is set in my.cnf, mysqld will refuse to honour and will not startup.

Possibly related to:
 
 Bug #60538	MySQL fails to start when max_connect_errors is set to 18446744073709547520
 http://bugs.mysql.com/bug.php?id=60538

 Bug #69704	Strangeness with max_binlog_stmt_cache_size Settings
 http://bugs.mysql.com/bug.php?id=69704

How to repeat:
Try setting the value in my.cnf and restart mysqld:
=====
2014-09-23 19:22:20 0 [ERROR] Incorrect integer value: '18446744073709547520'
2014-09-23 19:22:20 0 [Warning] option 'group_concat_max_len': unsigned value 0 adjusted to 4
2014-09-23 19:22:20 0 [ERROR] /mysql_master/mysql-5.6.20/bin/mysqld: Error while setting value '18446744073709547520' to 'group_concat_max_len'
2014-09-23 19:22:20 0 [ERROR] Aborting
=====
MySQL will not startup.

Works fine via prompt:
=====
mysql [localhost] {msandbox} ((none)) > SELECT @@global.group_concat_max_len;
+-------------------------------+
| @@global.group_concat_max_len |
+-------------------------------+
|                        666666 |
+-------------------------------+
1 row in set (0.00 sec)

mysql [localhost] {msandbox} ((none)) > SET GLOBAL group_concat_max_len=18446744073709547520;
Query OK, 0 rows affected (0.00 sec)

mysql [localhost] {msandbox} ((none)) > SELECT @@global.group_concat_max_len;
+-------------------------------+
| @@global.group_concat_max_len |
+-------------------------------+
|          18446744073709547520 |
+-------------------------------+
1 row in set (0.00 sec)
=====

Suggested fix:
Allow maximum 64 bit value to be set via my.cnf

[23 Sep 2014 16:05] Leandro Morgado

Possible workaround is to use init-file:

shell> cat my.cnf
[mysqld]
...
init-file=set_concat.sql

shell> cat set_concat.sql
set global group_concat_max_len=18446744073709547520;

mysql> SELECT @@global.group_concat_max_len;
+-------------------------------+
| @@global.group_concat_max_len |
+-------------------------------+
|          18446744073709547520 |
+-------------------------------+
1 row in set (0.00 sec)

[2 Feb 2015 16:06] Paul DuBois

Noted in 5.6.24, 5.7.6 changelogs.

The group_concat_max_len system variable could be set to its maximum
value at runtime, but not in an option file.

[27 Apr 2015 14:19] Laurynas Biveinis

commit 06c88ea14ad5946e4fcbe4e71fdfc28178a664f4
Author: V S Murthy Sidagam <[e-mail]>
Date:   Thu Feb 19 18:47:52 2015 +0530

    Bug #19670915 GROUP_CONCAT_MAX_LEN=18446744073709547520 NOT ACCEPTED IN MY.CNF
    
    Reverting the testcase because of having different size values in different platforms and architectures.

commit cac6fc837a5f72203058e4acc6b8b4dba8a98294
Author: V S Murthy Sidagam <[e-mail]>
Date:   Wed Jan 7 15:10:05 2015 +0530

    Description: According to the manual, the maximum value for group_concat_max_len in 64bit
    mysqld is 18446744073709547520. This works fine when set dynamically in the
    mysql command prompt. However, if the value is set in my.cnf, mysqld will refuse to honor
    and will not start up.
    
    Analysis: When the option group_concat_max_len is parsed and tries to store the given value,
    it will call eval_num_suffix() to convert the given value string to numeric value with the
    string function strtoll(). Since the give value won't fit in the longlong type an error is
    thrown and server refuse to start.
    
    Fix: As a fix we need to use strtoull() instead of strtoll(). which can accumulate the given
    unsigned longlong value.
    
    Note: This bug is already fixed in mysql-5.7 under bug #16491145. Hence used the same code changes to fix this bug as well.