- Fixed code that was not ready for a major version number > 9
- Fixed test cases that assumed max major version number could be 9
Updated version number for depricated options (will be removed in a later commit)
VERSION:
Version number 10.0.0
client/mysqlbinlog.cc:
Added support for major version numbers > 9
cmake/mysql_version.cmake:
Added support for version numbers that is 0
mysql-test/r/comments.result:
Modified test to handle version number 100000
mysql-test/r/func_system.result:
Modified test to handle version number 100000
mysql-test/r/log_state.result:
Updated depricated error message
mysql-test/r/sp.result:
Modified test to handle version number 100000
mysql-test/r/subselect4.result:
Updated depricated error message
mysql-test/r/variables.result:
Updated depricated error message
mysql-test/suite/rpl/r/rpl_conditional_comments.result:
Modified test to handle version number 100000
mysql-test/suite/rpl/r/rpl_loaddatalocal.result:
Modified test to handle version number 100000
mysql-test/suite/rpl/t/rpl_conditional_comments.test:
Modified test to handle version number 100000
mysql-test/suite/rpl/t/rpl_loaddatalocal.test:
Modified test to handle version number 100000
mysql-test/suite/sys_vars/r/debug_basic.result:
Updated depricated error message
mysql-test/suite/sys_vars/r/engine_condition_pushdown_basic.result:
Updated depricated error message
mysql-test/suite/sys_vars/r/log_basic.result:
Updated depricated error message
mysql-test/suite/sys_vars/r/log_slow_queries_basic.result:
Updated depricated error message
mysql-test/suite/sys_vars/r/multi_range_count_basic.result:
Updated depricated error message
mysql-test/suite/sys_vars/r/rpl_recovery_rank_basic.result:
Updated depricated error message
mysql-test/suite/sys_vars/r/sql_big_selects_func.result:
Updated depricated error message
mysql-test/suite/sys_vars/r/sql_max_join_size_basic.result:
Updated depricated error message
mysql-test/suite/sys_vars/r/sql_max_join_size_func.result:
Updated depricated error message
mysql-test/t/comments.test:
Modified test to handle version number 100000
mysql-test/t/file_contents.test:
Modified test to handle version number 100000
mysql-test/t/func_system.test:
Modified test to handle version number 100000
mysql-test/t/parser_not_embedded.test:
Modified test to handle version number 100000
mysql-test/t/sp.test:
Modified test to handle version number 100000
sql/mysqld.cc:
Updated version number for depricated options (will be removed in a later commit)
sql/slave.cc:
Modified test to handle version number 100000
Better error messages
sql/sql_lex.cc:
Modified test to handle version number 100000 in comment syntax
sql/sys_vars.cc:
Updated version number for depricated options (will be removed in a later commit)
Problem
========
SQL statements close to the size of max_allowed_packet produce binary
log events larger than max_allowed_packet.
The reason why this failure is occuring is because the event length is
more than the total size of the max_allowed_packet + max_event_header
length. Now since the event length exceeds this size master Dump
thread is unable to send the packet on to the slave.
That can happen e.g with row-based replication in Update_rows event.
Fix
====
The problem was fixed by increasing the max_allowed_packet for the
slave's threads (IO/SQL) by increasing it to 1GB.
This is done using the new server option included which is used to
regulate the max_allowed_packet of the slave thread (IO/SQL).
This causes the large packets to be received by the slave and apply
it successfully.
sql/log_event.h:
Added the new option in the log_event.h file.
sql/mysqld.cc:
Added a new option to the server.
sql/slave.cc:
Increasing the session max_allowed_packet to a large value ,
i.e. not taking global(max_allowed) into consideration, for the slave's threads.
Problem
========
SQL statements close to the size of max_allowed_packet produce binary
log events larger than max_allowed_packet.
The reason why this failure is occuring is because the event length is
more than the total size of the max_allowed_packet + max_event_header
length. Now since the event length exceeds this size master Dump
thread is unable to send the packet on to the slave.
That can happen e.g with row-based replication in Update_rows event.
Fix
====
The problem was fixed by increasing the max_allowed_packet for the
slave's threads (IO/SQL) by increasing it to 1GB.
This is done using the new server option included which is used to
regulate the max_allowed_packet of the slave thread (IO/SQL).
This causes the large packets to be received by the slave and apply
it successfully.
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
