Aligned client library build and use with the Unix version when it
comes to what source to include directly in the builds, and what
libraries to link with (bug#30118).
Also reviewed, corrected and made more clear when static or dynamic
Thread Local Storage is to be used. Some code duplication was removed,
and some redundant library usage were removed, reducing the risk of
incorrect TLS usage.
which does not work. Removing these attempted privileges makes
this identical to option 5 so remove it completely. The spirit
of the program appears to be aimed at database privileges, so do
not add another option for granting global privileges as it may
be unexpected. Fixes bug#14618 (same as previous patch, this
time applied to -maint tree).
to "my_config.h". Not to pollute the top directory, and to get more control
over what is included. Made the include path for "libedit" pick up its own
"config.h" first.
Don't use syslog by default; user will have to request it explicitly with the --syslog option.
Use "sed -u" to get unbuffered output from sed, if it's supported.
Otherwise, don't use sed at all - don't strip the timestamp from mysqld messages.
Also, add new --syslog-tag=FOO option, which adds "-FOO" to the tag used when logging messages to syslog (i.e., mysqld-FOO or mysqld_safe-FOO)
Also, explicitly mention where log messages are going, so user can more easily find them.
Also, check if 'logger' is in the PATH, and log to the error log file if it can't be found.
- make the 'dist-hook' from top-level Makefile work again.
- we can find my_print_defaults from --basedir by parsing command
line arguments prior to running my_print_defaults.
- take advantage of additional command line parsing and allow the
--no-defaults etc arguments to work anywhere rather than having
to be the first argument.
- find SQL files either from binary archive or source install.
- consolidate and tidy code and error messages.
5.1.20 -> 5.1.21 upgrades.
We generate mysql_fix_privilege.sql file, which contains SQL
statements required to upgrade the system database. This script
is generated by concatenation of mysql_system_tables.sql and
mysql_system_tables_fix.sql.
The problem was that
- in order to create general_log and slow_log tables we use
stored programs in mysql_system_tables.sql;
- we upgrade mysql.proc table in mysql_system_tables_fix.sql;
So, if mysql.proc table needs to be upgraded, stored procedures
can not be used in mysql_system_tables.sql.
In other words, in mysql_system_tables.sql stored programs must
not be used because they may be unavailable at this point.
The fix is to use dynamic SQL instead of stored programs.
There is no test case for this bug because our test suite
is not suitable for such test cases. system_mysql_db_fix* test
cases play with the database "test". Here we need to modify
the system database and we can not do that in the test suite.
available and reduce the chance of failure. This should fix bug#28585
which is caused by the script being quite random in how it finds files it
requires and not giving very good feedback to the user about what went
wrong.
Also update make_binary_distribution so that it provides the correct path
to the required SQL scripts when generating mysql_install_db. The script
only previously worked because of the permissive behaviour which looked
around the current working directory before the "correct" location. This
could lead to severe problems if the user happened to run the script from
a location which contained older or even broken copies of the SQL scripts.
We now require either a complete binary release (and the mysql_install_db
script ran from inside the extracted archive), or an installed compiled
tree, as this is the only way we can be sure everything that we need is
available and ready to run.
While working on this fix, also clean up the mysql_install_db script a lot
to make it simpler, easier to read, and hopefully less prone to bugs in
the future.
- 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;
Include all the additional test suites in the binary packages ("tar.gz").
This is the tar.gz part of the fixes for bug#26609; for RPMs it is already done.
