field_names[x][y] is a pointer
client/mysql.cc: In function 'void build_completion_hash(bool, bool)':
client/mysql.cc:2855:37: error: invalid conversion from 'char' to 'char*' [-fpermissive]
field_names[i][num_fields*2]= '\0';
Signed-off-by: Daniel Black <daniel.black@au.ibm.com>
When there are quotes in the USE statement, the mysql client does
not correctly escape them.
The USE statement is processed line by line from the client's parser,
and cannot handle multi-line commands as the server.
The fix is to escape the USE parameters whenever quotes are used.
Do not silence uncertain cases, or fix any bugs.
The only functional change should be that ha_federated::extra()
is not calling DBUG_PRINT to report an unhandled case for
HA_EXTRA_PREPARE_FOR_DROP.
CLIENT (CONTRIBUTION)
DESCRIPTION:
============
Binary data should be printed as hex in the mysql client
when the option binary-as-hex is enabled.
ANALYSIS:
=========
The fix deals only with mysql command line client.
It does not change, at all, the data sent to the
applications. Printing binary data as hex also
allows to use the output in the where clause
of the query.
FIX:
====
A new option 'binary-as-hex' is introduced to print the
binary contents as hex in the mysql client. The option
is disabled by default. When the option is enabled, we
convert the binary data to hex before printing the
contents irrespective of whether it is in tabular,
xml or html format.
While writing comments if database object names has a new
line character, then next line is considered a command, rather
than a comment.
This patch fixes the way comments are constructed in mysqldump.
(cherry picked from commit 1099f9d17b1c697c2760f86556f5bae7d202b444)
While writing comments if database object names has a new
line character, then next line is considered a command, rather
than a comment.
This patch fixes the way comments are constructed in mysqldump.
MYSQL_OPT_SSL_MODE option introduced.
It is set in case of --ssl-mode=REQUIRED and permits only SSL connection.
(cherry picked from commit 3b2d28578c526f347f5cfe763681eff365731f99)
Backport the fix to 5.5, because it fails there too
The patch fixes two test failures:
- on slow builders, sometimes a connection attempt which should
fail due to the exceeded number of thread_pool_max_threads
actually succeeds;
- on even slow builders, MTR sometimes cannot establish the
initial connection, and check-testcase fails prior to the
test start
The problem with check-testcase was caused by connect-timeout=2
which was set for all clients in the test config file. On slow
builders it might be not enough.
There is no way to override it for the pre-test check, so it needed
to be substantially increased or removed.
The other problem was caused by a race condition between sleeps
that the test performs in existing connections and the connect
timeout for the connection attempt which was expected to fail.
If sleeps finished before the connect-timeout was exceeded, it
would allow the connection to succeed.
To solve each problem without making the other one worse,
connect-timeout should be configured dynamically during the test.
Due to the nature of the test (all connections must be busy
at the moment when we need to change the timeout, and cannot execute
SET GLOBAL ...), it needs to be done independently from the server.
The solution:
- recognize 'connect_timeout' as a connection option in mysqltest's
"connect" command;
- remove connect-timeout from the test configuration file;
- use the new connect_timeout option for those connections which
are expected to fail;
- re-arrange the test flow to allow running a huge SLEEP
without affecting the test execution time (because it would be
interrupted after the main test flow is finished).
The test is still subject to false negatives, e.g. if the connection
fails due to timeout rather than due to the exceeded number of
allowed threads, or if the connection on extra port succeeds due
to a race condition and not because the special logic for the extra
port. But those false negatives have always been possible there
on slow builders, they should not be critical because faster builders
should catch such failures if they appear.
Conflicts:
client/mysqltest.cc
mysql-test/r/pool_of_threads.result
mysql-test/t/pool_of_threads.test
The patch fixes two test failures:
- on slow builders, sometimes a connection attempt which should
fail due to the exceeded number of thread_pool_max_threads
actually succeeds;
- on even slow builders, MTR sometimes cannot establish the
initial connection, and check-testcase fails prior to the
test start
The problem with check-testcase was caused by connect-timeout=2
which was set for all clients in the test config file. On slow
builders it might be not enough.
There is no way to override it for the pre-test check, so it needed
to be substantially increased or removed.
The other problem was caused by a race condition between sleeps
that the test performs in existing connections and the connect
timeout for the connection attempt which was expected to fail.
If sleeps finished before the connect-timeout was exceeded, it
would allow the connection to succeed.
To solve each problem without making the other one worse,
connect-timeout should be configured dynamically during the test.
Due to the nature of the test (all connections must be busy
at the moment when we need to change the timeout, and cannot execute
SET GLOBAL ...), it needs to be done independently from the server.
The solution:
- recognize 'connect_timeout' as a connection option in mysqltest's
"connect" command;
- remove connect-timeout from the test configuration file;
- use the new connect_timeout option for those connections which
are expected to fail;
- re-arrange the test flow to allow running a huge SLEEP
without affecting the test execution time (because it would be
interrupted after the main test flow is finished).
The test is still subject to false negatives, e.g. if the connection
fails due to timeout rather than due to the exceeded number of
allowed threads, or if the connection on extra port succeeds due
to a race condition and not because the special logic for the extra
port. But those false negatives have always been possible there
on slow builders, they should not be critical because faster builders
should catch such failures if they appear.
mysqldump/mysql_install_db.exe fail
The bug is described in
https://connect.microsoft.com/VisualStudio/Feedback/Details/1902345
When reading from a pipe in text mode, using CRT function such as fread(),
some newlines may be lost. Workaround is to use binary mode on reading side
and if necessary, replace \r\n with \n.
RUNNING FIREWALL
mysqladmin shutdown will try to extract the server's pid file before executing
the actual shutdown command.
It will do that by executing a SHOW VARIABLES query and processing the result.
However if that query fails it print a (somewhat confusing) error mesasage
and will still continue to do the shutdown command.
If that passes then the mysqladmin user will get an error but the shutdown will
still be successful.
This is confusing so the error message text is changed to say that this is a
non-fatal error and execution continues.
No test case added since it'd require a selective query failure device that's
not available in 5.5.
The issue was that when running with valgrind the wait for master_pos_Wait()
was not long enough.
This patch also fixes two other failures that could affect rpl_mdev6020:
- check_if_conflicting_replication_locks() didn't properly check domains
- 'did_mark_start_commit' was after signals to other threads was sent which could
get the variable read too early.
a correct fix:
* store properly quoted table names in tables4repair/etc lists
* tell handle_request_for_tables whether the name is aalready properly quoted
* test cases for all uses of fix_table_name()
It happens when you are trying to read two or more log files from a
remote server using mysqlbinlog utility.
The reason for this is no matching mysql_close() that concludes the
life time of 'mysql' struct describing connection to the server.
This happens when mysqlbinlog is invoked with connecting to the server
and requesting more than one binlog file. In such case
dump_remote_log_entries() keeps calling safe_connect() per eachfile,
never caring to invoke mysql_close(). Only the final safe_connect()'s
allocation effect are cleaned by the base code.
That is with 2 files there's one 'mysql' connection descriptor struct
uncleaned/deallocated.
We are backporting the bug 21255763 (pushed in mysql-trunk)
in the earlier version of MySQL starting from 5.5 to 5.7.
which was pushed in mysql-trunk.
Fix:
Invoke mysql_close() just before mysql_init() in safe_connect()
defined in mysqlbinlog.cc. That makes possibly previously used 'mysql' be
reclaimed prior a new one is allocated.
