server
If the server connection was lost during repeated status commands,
the client would fail to detect this and the client output would be inconsistent.
This patch fixes this issue by making sure that the server is online
before the client attempts to execute the status command.
The problem: described in the bug report.
The fix:
--increase buffers where it's necessary
(buffers which are used in stxnmov)
--decrease buffer lengths which are used
memory issue ?
The mysql command line client could misinterpret some character
sequences as commands under some circumstances.
The upper limit for internal readline buffer was raised to 1 GB
(the same as for server's max_allowed_packet) so that any input
line is processed by add_line() as a whole rather than in
chunks.
When asking what database is selected, client expected
to *always* get an answer from the server.
We now handle failure more gracefully.
See comments in ticket for a discussion of what happens,
and how things interlock.
mysql-client used static buffer to concatenate server-
version and version_comment. Sufficiently long comments
could get cut off. This was harmless, but looked daft.
Now using a dynamic buffer instead.
~40Mb after mysqldump/import
When the input string exceeds the maximum allowed size for the
internal buffer, batch_readline() returns a truncated string.
Since there was no way for a caller to determine whether the
string was truncated or not, the command line client assumed
batch_readline() to always return the whole input string and
appended a newline character. This resulted in garbled data
when importing dumps containing strings longer than the
maximum input buffer size.
Fixed by adding a flag to the batch_readline() interface to
signal a truncated string to the caller.
Other minor problems fixed during patch implementation:
- The maximum allowed buffer size for batch_readline() was set
up depending on the client's max_allowed_packet value. It does
not actully make any sense, as those variables are not
related. The input buffer size limit is now always set to 1
MB.
- fill_buffer() did not always set the EOF flag.
- The input buffer could actually grow twice as the specified
limit due to insufficient checks in intern_read_line().
There was a problem when a DELIMITER COMMAND is not the first
command on the line. I this case an extra line feed was added
to the glob buffer and this was causing subsequent attempts
to enter this delimiter to fail.
Fixed by not adding a new line to the glob buffer if the
command being added is a DELIMITER
There was a problem when a DELIMITER COMMAND is not the first
command on the line. I this case an extra line feed was added
to the glob buffer and this was causing subsequent attempts
to enter this delimiter to fail.
Fixed by not adding a new line to the glob buffer if the
command being added is a DELIMITER
Typo existed in help-text for command "charset" in mysql
client, making the parameter-name different for long and
short forms of the command for no good reason.
Fixed.
- Remove bothersome warning messages. This change focuses on the warnings
that are covered by the ignore file: support-files/compiler_warnings.supp.
- Strings are guaranteed to be max uint in length
The fix for BUG#20103 "Escaping with backslash does not work as expected"
was implemented too greedy though in that it not only changes the behavior
of backslashes within strings but in general, so disabling command shortcuts
like \G or \C (which in turn leads to Bug #36391: "mysqlbinlog creates invalid charset
statements").
The fix allows the escaping with backslash to take place only inside a string,
thus enabling the execution of command shortcuts and presevering the fix for
BUG#20103.
Fix parsing of mysql client commands, especially in relation to
single-line comments when --comments was specified.
This is a little tricky, because we need to allow single-line
comments in the middle of statements, but we don't want to allow
client commands in the middle of statements. So in
comment-preservation mode, we go ahead and send single-line
comments to the server immediately when we encounter them on their
own.
This is still slightly flawed, in that it does not handle a
single-line comment with leading spaces, followed by a client-side
command when --comment has been enabled. But this isn't a new
problem, and it is quite an edge condition. Fixing it would require
a more extensive overall of how the mysql client parses commands.
The problem here is that embedded server starts handle_thread manager
thread on mysql_library_init() does not stop it on mysql_library_end().
At shutdown, my_thread_global_end() waits for thread count to become 0,
but since we did not stop the thread it will give up after 5 seconds.
Solution is to move shutdown for handle_manager thread from kill_server()
(mysqld specific) to clean_up() that is used by both embedded and mysqld.
This patch also contains some refactorings - to avoid duplicate code,
start_handle_manager() and stop_handle_manager() functions are introduced.
Unused variables are eliminated. handle_manager does not rely on global
variable abort_loop anymore to stop (abort_loop is not set for embedded).
Note: Specifically on Windows and when using DBUG version of libmysqld,
the complete solution requires removing obsolete code my_thread_init()
from my_thread_var(). This has a side effect that a DBUG statement
after my_thread_end() can cause thread counter to be incremented, and
embedded will hang for some seconds. Or worse, my_thread_init() will
crash if critical sections have been deleted by the global cleanup
routine that runs in a different thread.
This patch also fixes and revert prior changes for Bug#38293
"Libmysqld crash in mysql_library_init if language file missing".
Root cause of the crash observed in Bug#38293 was bug in my_thread_init()
described above
Bug#33812: mysql client incorrectly parsing DELIMITER
Remove unnecessary and incorrect code that tried
to pull delimiter commands out of the middle of
statements.
