become negative
- merged the fix to 5.1
- extended to cover I_S.PROCESSLIST.TIME
- Changed the column type of I_S.PROCESSLIST.TIME from LOGNLONG
UNSIGNED
to LONG (to match the SHOW PROCESSLIST type)
- Added a test case
Bug#42003 tests missing the disconnect of connections <> default
second slice
Content:
1. wait_until_count_sessions.inc
- One PB run of a test using this routine failed because
5 seconds timeout were exceeded. Although I have some doubts
if the assigned timeout was really too small, I increase the
value to 10. We waste the additional 5 seconds only if the
tests fails anyway.
- Print the content of the PROCESSLIST if the poll routine fails
2. minor improvements of formatting
3. query_cache_notembedded:
Activate the wait_until_count_sessions.inc routine which was
unfortunately forgotten in the changeset before.
- If missing: add "disconnect <session>"
- If physical disconnect of non "default" sessions is not finished
at test end: add routine which waits till this happened
+ additional improvements
- remove superfluous files created by the test
- replace error numbers by error names
- remove trailing spaces, replace tabs by spaces
- unify writing of bugs within comments
- correct comments
- minor changes of formatting
Fixed tests:
backup
check
compress
grant
information_schema
multi_update
overflow
packet
query_cache_not_embedded
sp-threads
subselect
synchronization
timezone_grant
conflicts:
Text conflict in client/mysqltest.cc
Text conflict in mysql-test/include/wait_until_connected_again.inc
Text conflict in mysql-test/lib/mtr_report.pm
Text conflict in mysql-test/mysql-test-run.pl
Text conflict in mysql-test/r/events_bugs.result
Text conflict in mysql-test/r/log_state.result
Text conflict in mysql-test/r/myisam_data_pointer_size_func.result
Text conflict in mysql-test/r/mysqlcheck.result
Text conflict in mysql-test/r/query_cache.result
Text conflict in mysql-test/r/status.result
Text conflict in mysql-test/suite/binlog/r/binlog_index.result
Text conflict in mysql-test/suite/binlog/r/binlog_innodb.result
Text conflict in mysql-test/suite/rpl/r/rpl_packet.result
Text conflict in mysql-test/suite/rpl/t/rpl_packet.test
Text conflict in mysql-test/t/disabled.def
Text conflict in mysql-test/t/events_bugs.test
Text conflict in mysql-test/t/log_state.test
Text conflict in mysql-test/t/myisam_data_pointer_size_func.test
Text conflict in mysql-test/t/mysqlcheck.test
Text conflict in mysql-test/t/query_cache.test
Text conflict in mysql-test/t/rpl_init_slave_func.test
Text conflict in mysql-test/t/status.test
GLOBAL STATUS is calculated by studying the list of threads. In the
embedded server threads were not linked to the internal list, so the
calculation always returns 0. Fixed by 'linking' the embedded-server
threads to the same list
per-file comments:
libmysqld/lib_sql.cc
Bug#34517 SHOW GLOBAL STATUS does not work properly in embedded server.
Add newly created 'threads' to the internal thread list.
Remove them from the list as they're freed.
mysql-test/r/information_schema.result
Bug#34517 SHOW GLOBAL STATUS does not work properly in embedded server.
test result
mysql-test/t/information_schema.test
Bug#34517 SHOW GLOBAL STATUS does not work properly in embedded server.
test case added
VARIABLE_VALUE field is decreased to 1024 symbols.
(affected I_S tables: GLOBAL_VARIABLES, SESSION_VARIABLES,
GLOBAL_STATUS, SESSION_STATUS).
The only variable which can be longer than 1024 is
init_connect. The variable will be truncated with warning.
Additional fix:
Added where condition filter which speed up queries which
have where condition with expressions which use VARIABLE_NAME
field.
When swapping out heap I_S tables to disk, this is done after plan refinement.
Thus, READ_RECORD::file will still point to the (deleted) heap handler at start
of execution. This causes segmentation fault if join buffering is used and the
query is a star query where the result is found to be empty before accessing
some table. In this case that table has not been initialized (i.e. had its
READ_RECORD re-initialized) before the cleanup routine tries to close the handler.
Fixed by updating READ_RECORD::file when changing handler.
m_status == DA_OK
Reading from information_scema.tables or information_schema.columns
may cause assertion failure in debug builds. This may happen under
rare circumstances when information_schema fails to get information
about a table (e.g. when a connection is killed).
This happens because open_normal_and_derived_tables() can return an
error without setting an error message in THD. But information_schema
attempts to get an error message from THD unconditionally.
With this fix information_schema attempts to get an error message
from THD only in case error message is set in THD.
pre-locking.
The crash was caused by an implicit assumption in check_table_access() that
table_list parameter is always a part of lex->query_tables.
When iterating over the passed list of tables, check_table_access() used
to stop only when lex->query_tables_last_not_own was reached.
In case of pre-locking, lex->query_tables_last_own is not NULL and points
to some element of lex->query_tables. When the parameter
of check_table_access() was not part of lex->query_tables, loop invariant
could never be violated and a crash would happen when the current table
pointer would point beyond the end of the provided list.
The fix is to change the signature of check_table_access() to also accept
a numeric limit of loop iterations, similarly to check_grant(), and
supply this limit in all places when we want to check access of tables
that are outside lex->query_tables, or just want to check access to one table.
command and reported to a client.
The fact that a timestamp field will be set to NO on UPDATE wasn't shown
by the SHOW COMMAND and reported to a client through connectors. This led to
problems in the ODBC connector and might lead to a user confusion.
A new filed flag called ON_UPDATE_NOW_FLAG is added.
Constructors of the Field_timestamp set it when a field should be set to NOW
on UPDATE.
The get_schema_column_record function now reports whether a timestamp field
will be set to NOW on UPDATE.
wait_condition timeout.
The problem was that the event thread didn't manage to execute
the event in 30 seconds on highly-loaded box. The fix is to
increase timeout.
This is a fix for the test suite.
"DECLARE CURSOR FOR SHOW ..." is a syntax that currently appears to work,
but is untested for some SHOW commands and does not work for other SHOW
commands.
Since this is an un-intended feature that leaked as a result of a coding bug
(in the parser grammar), the correct fix is to fix the grammar to not accept
this construct.
In other words, "DECLARE CURSOR FOR SHOW <other commands that don't work>"
is not considered a bug, and we will not implement other features to make all
the SHOW commands usable inside a cursor just because someone exploited a bug.
added get_field_default_value() function which obtains default value from the field
(used in store_create_info() & get_schema_column_record() functions)
1. added check to fill_schema_schemata() func.
if we have db lookup value we should check that db exists
2. added check to get_all_tables() func
if we have lookup db name or tables name values we shoud check that
these values are not empty strings
3. fixed typo
- BUG#11986: Stored routines and triggers can fail if the code
has a non-ascii symbol
- BUG#16291: mysqldump corrupts string-constants with non-ascii-chars
- BUG#19443: INFORMATION_SCHEMA does not support charsets properly
- BUG#21249: Character set of SP-var can be ignored
- BUG#25212: Character set of string constant is ignored (stored routines)
- BUG#25221: Character set of string constant is ignored (triggers)
There were a few general problems that caused these bugs:
1. Character set information of the original (definition) query for views,
triggers, stored routines and events was lost.
2. mysqldump output query in client character set, which can be
inappropriate to encode definition-query.
3. INFORMATION_SCHEMA used strings with mixed encodings to display object
definition;
1. No query-definition-character set.
In order to compile query into execution code, some extra data (such as
environment variables or the database character set) is used. The problem
here was that this context was not preserved. So, on the next load it can
differ from the original one, thus the result will be different.
The context contains the following data:
- client character set;
- connection collation (character set and collation);
- collation of the owner database;
The fix is to store this context and use it each time we parse (compile)
and execute the object (stored routine, trigger, ...).
2. Wrong mysqldump-output.
The original query can contain several encodings (by means of character set
introducers). The problem here was that we tried to convert original query
to the mysqldump-client character set.
Moreover, we stored queries in different character sets for different
objects (views, for one, used UTF8, triggers used original character set).
The solution is
- to store definition queries in the original character set;
- to change SHOW CREATE statement to output definition query in the
binary character set (i.e. without any conversion);
- introduce SHOW CREATE TRIGGER statement;
- to dump special statements to switch the context to the original one
before dumping and restore it afterwards.
Note, in order to preserve the database collation at the creation time,
additional ALTER DATABASE might be used (to temporary switch the database
collation back to the original value). In this case, ALTER DATABASE
privilege will be required. This is a backward-incompatible change.
3. INFORMATION_SCHEMA showed non-UTF8 strings
The fix is to generate UTF8-query during the parsing, store it in the object
and show it in the INFORMATION_SCHEMA.
Basically, the idea is to create a copy of the original query convert it to
UTF8. Character set introducers are removed and all text literals are
converted to UTF8.
This UTF8 query is intended to provide user-readable output. It must not be
used to recreate the object. Specialized SHOW CREATE statements should be
used for this.
The reason for this limitation is the following: the original query can
contain symbols from several character sets (by means of character set
introducers).
Example:
- original query:
CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1;
- UTF8 query (for INFORMATION_SCHEMA):
CREATE VIEW v1 AS SELECT 'Hello' AS c1;
