TO "LOCALHOST" IF LOCALHOST IS BOTH IPV4/IPV6 ENABLED.
Previous commit comments were wrong. The default value has always been NULL.
The original patch for Bug#12762885 just makes it visible in the logs.
This patch uses "0.0.0.0" string if bind-address is not set.
TO "LOCALHOST" IF LOCALHOST IS BOTH IPV4/IPV6 ENABLED.
Previous commit comments were wrong. The default value has always been NULL.
The original patch for Bug#12762885 just makes it visible in the logs.
This patch uses "0.0.0.0" string if bind-address is not set.
IF LOCALHOST IS BOTH IPV4/IPV6 ENABLED.
The original patch removed default value of the bind-address option.
So, the default value became NULL. By coincedence NULL resolves
to 0.0.0.0 and ::, and since the server chooses first IPv4-address,
0.0.0.0 is choosen. So, there was no change in the behaviour.
This patch restores default value of the bind-address option to "0.0.0.0".
IF LOCALHOST IS BOTH IPV4/IPV6 ENABLED.
The original patch removed default value of the bind-address option.
So, the default value became NULL. By coincedence NULL resolves
to 0.0.0.0 and ::, and since the server chooses first IPv4-address,
0.0.0.0 is choosen. So, there was no change in the behaviour.
This patch restores default value of the bind-address option to "0.0.0.0".
IF LOCALHOST IS BOTH IPV4/IPV6 ENABLED.
The original patch removed default value of the bind-address option.
So, the default value became NULL. By coincedence NULL resolves
to 0.0.0.0 and ::, and since the server chooses first IPv4-address,
0.0.0.0 is choosen. So, there was no change in the behaviour.
This patch restores default value of the bind-address option to "0.0.0.0".
IF LOCALHOST IS BOTH IPV4/IPV6 ENABLED.
The original patch removed default value of the bind-address option.
So, the default value became NULL. By coincedence NULL resolves
to 0.0.0.0 and ::, and since the server chooses first IPv4-address,
0.0.0.0 is choosen. So, there was no change in the behaviour.
This patch restores default value of the bind-address option to "0.0.0.0".
Problem - The cause of the failure is mainly due to the assert added in
the code as a result of the fix of the BUG-13333431. When we
start the server with the --skip-networking option enabled
we have the mysqld_port explicitly to 0. Since the value of
report_port is set to mysqld_port, the assertion that
(report_port!= 0) fails.
Fix - the fix of the problem is to assert the not zero value of
report_port only in the case the --skip-networking option is not
used to start the mysqld server.
sql/mysqld.cc:
Added the code to check for the skip-networking option while starting
the server.
Problem - The cause of the failure is mainly due to the assert added in
the code as a result of the fix of the BUG-13333431. When we
start the server with the --skip-networking option enabled
we have the mysqld_port explicitly to 0. Since the value of
report_port is set to mysqld_port, the assertion that
(report_port!= 0) fails.
Fix - the fix of the problem is to assert the not zero value of
report_port only in the case the --skip-networking option is not
used to start the mysqld server.
IPV4/IPV6 ENABLED
Analysis:
----------------------
The problem was that if a hostname resolves to more than one IP-address,
the server (5.5) does not start due to an error. In 5.1 the server used to
take some IP-address and start.
It's a regression and should be fixed.
5.5 supports IPv6, while 5.1 does not. However, that should not
prevent the server from start -- if a hostname has both IPv4 and IPv6 addresses,
the server should choose some IPv4-address and start.
It's been decided to prefer IPv4-address to be backward compatible with 5.1.
Another problem was that the 5.6 server did not report proper error message
when the specified hostname could not be resolved. So, the code has been
changed to report proper error message.
Testing
================================
5.5
=============================
invalid hostname (localhos):
=> Following error message reported.
120308 15:52:09 [ERROR] Can't start server: cannot resolve hostname!
120308 15:52:09 [ERROR] Aborting
invalid ip_address:
=> Following error message reported.
120308 15:56:06 [Note] Server hostname (bind-address): '123.123.123.123'; port: 3306
120308 15:56:06 [Note] - '123.123.123.123' resolves to '123.123.123.123';
120308 15:56:06 [Note] Server socket created on IP: '123.123.123.123'.
120308 15:56:06 [ERROR] Can't start server: Bind on TCP/IP port: Cannot assign requested address
Only ipv4 host configured:
=> Following message logged
120308 16:02:50 [Note] Server hostname (bind-address): 'localhost'; port: 3306
120308 16:02:50 [Note] - 'localhost' resolves to '127.0.0.1';
120308 16:02:50 [Note] Server socket created on IP: '127.0.0.1'
Only ipv6 host configured:
=> Following message logged
120308 16:04:03 [Note] Server hostname (bind-address): 'localhost'; port: 3306
120308 16:04:03 [Note] - 'localhost' resolves to '::1';
120308 16:04:03 [Note] Server socket created on IP: '::1'.
ipv4 and ipv6 host configured:
=> Following message logged
120308 16:05:02 [Note] Server hostname (bind-address): 'localhost'; port: 3306
120308 16:05:02 [Note] - 'localhost' resolves to '::1';
120308 16:05:02 [Note] - 'localhost' resolves to '127.0.0.1';
120308 16:05:02 [Note] Server socket created on IP: '127.0.0.1'.
=> Non localhost address
120308 16:08:20 [Note] Server hostname (bind-address): 'mysql_addr'; port: 3306
120308 16:08:20 [Note] - 'mysql_addr' resolves to '10.178.58.216';
120308 16:08:20 [Note] - 'mysql_addr' resolves to 'fe80::120b:a9ff:fe69:59ec';
120308 16:08:20 [Note] Server socket created on IP: '10.178.58.216'.
More than one entry for ipv4 and ipv6 address:
=> Following message logged
120308 16:06:19 [Note] Server hostname (bind-address): 'localhost'; port: 3306
120308 16:06:19 [Note] - 'localhost' resolves to '::1';
120308 16:06:19 [Note] - 'localhost' resolves to '::1';
120308 16:06:19 [Note] - 'localhost' resolves to '127.0.0.1';
120308 16:06:19 [Note] - 'localhost' resolves to '127.0.0.1';
120308 16:06:19 [Note] Server socket created on IP: '127.0.0.1'.
IPV4/IPV6 ENABLED
Analysis:
----------------------
The problem was that if a hostname resolves to more than one IP-address,
the server (5.5) does not start due to an error. In 5.1 the server used to
take some IP-address and start.
It's a regression and should be fixed.
5.5 supports IPv6, while 5.1 does not. However, that should not
prevent the server from start -- if a hostname has both IPv4 and IPv6 addresses,
the server should choose some IPv4-address and start.
It's been decided to prefer IPv4-address to be backward compatible with 5.1.
Another problem was that the 5.6 server did not report proper error message
when the specified hostname could not be resolved. So, the code has been
changed to report proper error message.
Testing
================================
5.5
=============================
invalid hostname (localhos):
=> Following error message reported.
120308 15:52:09 [ERROR] Can't start server: cannot resolve hostname!
120308 15:52:09 [ERROR] Aborting
invalid ip_address:
=> Following error message reported.
120308 15:56:06 [Note] Server hostname (bind-address): '123.123.123.123'; port: 3306
120308 15:56:06 [Note] - '123.123.123.123' resolves to '123.123.123.123';
120308 15:56:06 [Note] Server socket created on IP: '123.123.123.123'.
120308 15:56:06 [ERROR] Can't start server: Bind on TCP/IP port: Cannot assign requested address
Only ipv4 host configured:
=> Following message logged
120308 16:02:50 [Note] Server hostname (bind-address): 'localhost'; port: 3306
120308 16:02:50 [Note] - 'localhost' resolves to '127.0.0.1';
120308 16:02:50 [Note] Server socket created on IP: '127.0.0.1'
Only ipv6 host configured:
=> Following message logged
120308 16:04:03 [Note] Server hostname (bind-address): 'localhost'; port: 3306
120308 16:04:03 [Note] - 'localhost' resolves to '::1';
120308 16:04:03 [Note] Server socket created on IP: '::1'.
ipv4 and ipv6 host configured:
=> Following message logged
120308 16:05:02 [Note] Server hostname (bind-address): 'localhost'; port: 3306
120308 16:05:02 [Note] - 'localhost' resolves to '::1';
120308 16:05:02 [Note] - 'localhost' resolves to '127.0.0.1';
120308 16:05:02 [Note] Server socket created on IP: '127.0.0.1'.
=> Non localhost address
120308 16:08:20 [Note] Server hostname (bind-address): 'mysql_addr'; port: 3306
120308 16:08:20 [Note] - 'mysql_addr' resolves to '10.178.58.216';
120308 16:08:20 [Note] - 'mysql_addr' resolves to 'fe80::120b:a9ff:fe69:59ec';
120308 16:08:20 [Note] Server socket created on IP: '10.178.58.216'.
More than one entry for ipv4 and ipv6 address:
=> Following message logged
120308 16:06:19 [Note] Server hostname (bind-address): 'localhost'; port: 3306
120308 16:06:19 [Note] - 'localhost' resolves to '::1';
120308 16:06:19 [Note] - 'localhost' resolves to '::1';
120308 16:06:19 [Note] - 'localhost' resolves to '127.0.0.1';
120308 16:06:19 [Note] - 'localhost' resolves to '127.0.0.1';
120308 16:06:19 [Note] Server socket created on IP: '127.0.0.1'.
Fixed compilation problem on windows.
configure.cmake:
Added test for pthread_attr_getguardsize
include/my_stacktrace.h:
Define dummy my_init_stacktrace() to allow one to call it without #ifdef HAVE_STACKTRACE
sql/mysqld.cc:
Move my_setstacksize() to fix compilation problem on windows
Don't disable core on signal just becasue platform doesn't handle stack trace
Fixed failing tests in sys_vars as we have now stricter checking of setting of variables.
mysql-test/suite/sys_vars/r/innodb_adaptive_flushing_basic.result:
One can now only assign 0 or 1 to boolean variables
mysql-test/suite/sys_vars/r/innodb_adaptive_hash_index_basic.result:
One can now only assign 0 or 1 to boolean variables
mysql-test/suite/sys_vars/r/innodb_large_prefix_basic.result:
One can now only assign 0 or 1 to boolean variables
mysql-test/suite/sys_vars/r/innodb_random_read_ahead_basic.result:
One can now only assign 0 or 1 to boolean variables
mysql-test/suite/sys_vars/r/innodb_stats_on_metadata_basic.result:
One can now only assign 0 or 1 to boolean variables
mysql-test/suite/sys_vars/r/innodb_strict_mode_basic.result:
One can now only assign 0 or 1 to boolean variables
mysql-test/suite/sys_vars/r/innodb_support_xa_basic.result:
One can now only assign 0 or 1 to boolean variables
mysql-test/suite/sys_vars/r/innodb_table_locks_basic.result:
One can now only assign 0 or 1 to boolean variables
mysql-test/suite/sys_vars/r/rpl_semi_sync_master_enabled_basic.result:
One can now only assign 0 or 1 to boolean variables
mysql-test/suite/sys_vars/r/rpl_semi_sync_slave_enabled_basic.result:
One can now only assign 0 or 1 to boolean variables
mysql-test/suite/sys_vars/t/innodb_adaptive_flushing_basic.test:
One can now only assign 0 or 1 to boolean variables
mysql-test/suite/sys_vars/t/innodb_adaptive_hash_index_basic.test:
One can now only assign 0 or 1 to boolean variables
mysql-test/suite/sys_vars/t/innodb_large_prefix_basic.test:
One can now only assign 0 or 1 to boolean variables
mysql-test/suite/sys_vars/t/innodb_random_read_ahead_basic.test:
One can now only assign 0 or 1 to boolean variables
mysql-test/suite/sys_vars/t/innodb_stats_on_metadata_basic.test:
One can now only assign 0 or 1 to boolean variables
mysql-test/suite/sys_vars/t/innodb_strict_mode_basic.test:
One can now only assign 0 or 1 to boolean variables
mysql-test/suite/sys_vars/t/innodb_support_xa_basic.test:
One can now only assign 0 or 1 to boolean variables
mysql-test/suite/sys_vars/t/innodb_table_locks_basic.test:
One can now only assign 0 or 1 to boolean variables
mysys/my_getsystime.c:
Merge + fixed bug that __NR_clock_gettime didn't work in 5.5
mysql-test/suite/innodb/t/group_commit_crash.test:
remove autoincrement to avoid rbr being used for insert ... select
mysql-test/suite/innodb/t/group_commit_crash_no_optimize_thread.test:
remove autoincrement to avoid rbr being used for insert ... select
mysys/my_addr_resolve.c:
a pointer to a buffer is returned to the caller -> the buffer cannot be on the stack
mysys/stacktrace.c:
my_vsnprintf() is ok here, in 5.5
modified for MySQL 5.5. Logger service moved to the
plugin/sql_errlog directory to be properly used later.
plugin/sql_errlog/sql_errlog.c:
Fixes for bugs #956427 (SQL_ERROR_LOG plugin produces bogus warnings about sql-error-log-size-limit value) and #956463 (Server crashes if SQL_ERROR_LOG fails to initialize) they're also MDEV-184 and MDEV-183
The sql_error_log_deinit() should be prepared for the logger_file to be NULL.
The logger_file_size_limit upper limit wasn't properly set.
- Don't use SAFEMALLOC on valgrind builds (slows things down)
- Added back lost option from 5.3: debug-mutex-deadlock-detector
- Flush pages before taking lock mutex (speeds up closing of Aria tables).
BUILD/SETUP.sh:
- Don't use SAFEMALLOC on valgrind builds (slows things down)
sql/lock.cc:
Make default argument explicit (improves readability)
sql/mysqld.cc:
Removed compiler warnings
Sorted debug options alphabetically
Added back lost option from 5.3: debug-mutex-deadlock-detector
storage/maria/ma_close.c:
Flush pages before taking lock mutex (speeds up closing of Aria tables).
storage/maria/ma_open.c:
More DBUG_PRINT
storage/maria/maria_def.h:
Better DBUG_PRINT
storage/maria/trnman.c:
Better DBUG_PRINT
Added the logger service that provides us with the rotating logs.
The plugin SQL_ERROR_LOG added. It logs the errors using the 'logger service'
for the rotating log files.
the example record from the log:
2012-03-09 15:07:29 root[root] @ localhost [] ERROR 1146: Table 'test.xyz' doesn't exist : select * from test.xyz
