expired timeout on debx86-b in PB
Moved the resource-intensive test case for bug #41486 into
a separate test file to reduce execution time for mysql.test.
~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
When substituting system constant functions with a constant result
the server was not expecting that the function may return NULL.
Fixed by checking for NULL and returning Item_null (in the relevant
collation) if the result of the system constant function was NULL.
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.
Bug#33812: mysql client incorrectly parsing DELIMITER
Remove unnecessary and incorrect code that tried
to pull delimiter commands out of the middle of
statements.
In several cases, an error when processing the query would cause mysql to
return to the top level without printing warnings. Fix is to always
print any available warnings before returning to the top level.
added get_field_default_value() function which obtains default value from the field
(used in store_create_info() & get_schema_column_record() functions)
Problem:
In cases when a client-side macro appears inside a server-side comment, the add_line() function in mysql.cc discarded all characters until the next delimiter to remove macro arguments from the query string. This resulted in broken queries being sent to the server when the next delimiter character appeared past the comment's boundaries, because the comment closing sequence ('*/') was discarded.
Fix:
If a client-side macro appears inside a server-side comment, discard all characters in the comment after the macro (that is, until the end of the comment rather than the next delimiter).
This is a minimal fix to allow only simple cases used by the mysqlbinlog utility. Limitations that are worth documenting:
- Nested server-side and/or client-side comments are not supported by mysql.cc
- Using client-side macros in multi-line server-side comments is not supported
- All characters after a client-side macro in a server-side comment will be omitted from the query string (and thus, will not be sent to server).
bug #27715: mysqld --character-sets-dir buffer overflow
bug ##26851: Mysql Client --pager Buffer Overflow
Using strmov() to copy an argument may cause overflow
if the argument's length is bigger than the buffer:
use strmake instead.
Also, we have to encrease the error message buffer size to fit
the longest message.
The problem happened because those tests were using "cp932" and "ucs2" without checking whether these character sets are available. This fix moves test parts to make character set specific parts be tested only if they are:
- some parts were moved to "ctype_ucs.test" and "ctype_cp932.test"
- some parts were moved to the newly added tests "innodb-ucs2.test", "mysqlbinglog-cp932.test" and "sp-ucs2.test"
- Client side readline functions unconditionally search for Unix '\n' line
endings. In this case, the delimiter statement was set to '//\r' instead
of the intended '//'. When removing the '\n' check for and remove
preceeding '\r' character as well.
The column's NOT NULL flag doesn't affect what we should print. Remove the
wrong logic that does check it.
Also, verify that this and the previous two tests print the same data as
other output formats.
The mysql client uses the default character set on reconnect. The default character set is now controled by the client charset command while the client is running. The charset command now also issues a SET NAMES command to the server to make sure that the client's charset settings are in sync with the server's.
