Ensure that 'null_value' is not accessed before val() is called in FIELD() functions
Fixed initialization of key maps. This fixes some problems with keys when you have more than 64 keys
Fixed that ROLLUP don't always create a temporary table. This fix ensures that func_gconcat.test results are now predictable
CREATE DATABASE statement used the current database instead of the
database created when checking conditions for replication.
CREATE/DROP/ALTER DATABASE statements are now replicated based on
the manipulated database.
Replication using replicate-rewrite-db did not work for LOAD DATA INFILE.
Now is does. There was one place in the code that used current database
instead of the rewrite database.
Now thd->mem_root is a pointer to thd->main_mem_root and THR_MALLOC is a pointer to thd->mem_root.
This gives us the following benefits:
- Allow us to easily detect if arena has already been swapped before (this fixes a bug in setup_conds() where arena was swaped twice in some cases)
- Faster swaps of arenas (as we don't have to copy the whole MEM_ROOT)
- We don't anymore have to call my_pthread_setspecific_ptr(THR_MALLOC,...) to change where memory is alloced. Now it's enough to set thd->mem_root
as we already have db_len in Log_event. Only if rewrite_db() changed the db we need a strlen
(so we now do the strlen() in rewrite_db). Plus a test (we had none for --replicate-rewrite-db :( ).
We must not reset the charset in slave after each statement, otherwise the SET CHARACTER SET is cancelled immediately.
Instead, we write a SET CHARACTER SET DEFAULT to the master's binlog when needed (like we already do for SET FOREIGN_KEY_CHECKS);
such writing is not necessary in 4.1 (in 4.1 the bug does not exist, as the SET ONE_SHOT syntax is used).
I have written a test and it works, but I'm not pushing the test as it requires building with all charsets.
I have noticed differences between what is inserted in the master's table in 4.0 and 4.1, and alerted Bar.
client code and replication slave code, as far as LOAD DATA INFILE and
other queries' execution is concerned. Duplication of code leads to
replication bugs, because the replication duplicate lags much behind.
Fix for 2 Valgrind errors on slave replicating LOAD DATA INFILE
- one serious (causing a random test failure in rpl_loaddata in 5.0)
- one not serious (theoretically a bug but not dangerous): uninited thd->row_count
processlist on slave":
we now report in SHOW PROCESSLIST that we are writing to the temp
files or loading the table. When we are writing to the tmp file:
| 3 | system user | | | Connect | 6 | Making temp file /tmp/SQL_LOAD-2-1-2.data |
and when we are actually loading the .data temp file into the table:
| 3 | system user | | test | Connect | 2 | | LOAD DATA INFILE '/tmp/SQL_LOAD-2-1-2.data' INTO TABLE `t` <...> |
In mysqlbinlog, there was a problem with how we escaped the content of a string user variable.
To be perfect, we should have escaped with character_set_client. But this charset is unknown
to mysqlbinlog. So the simplest is to print the string in hex. This is unreadable but
100% safe with any charset (checked with Bar), no more need to bother with character_set_client.
by binlogging some SET ONE_SHOT CHARACTER_SETetc,
which will be enough until we have it more compact and more complete in 5.0. With the present patch,
replication will work ok between 4.1.3 master and slaves, as long as:
- master and slave have the same GLOBAL.COLLATION_SERVER
- COLLATION_DATABASE and CHARACTER_SET_DATABASE are not used
- application does not use the fact that table is created with charset of the USEd db (BUG#2326).
all of which are not too hard to fulfill.
ONE_SHOT is reserved for internal use of mysqlbinlog|mysql and works only for charsets,
so we give error if used for non-charset vars.
Fix for BUG#3875 "mysqlbinlog produces wrong ouput if query uses
variables containing quotes" and BUG#3943 "Queries with non-ASCII literals are not replicated
properly after SET NAMES".
Detecting that master and slave have different global charsets or server ids.
Fix remaining cases of Bug #3596: fix possible races caused by an obsolete value of thd->query_length in SHOW PROCESSLIST and SHOW INNODB STATUS; this fix depends on the fact that thd->query is always set to NULL before setting it to point to a new query
in hard-coded replication messages, always put small-length info (error codes, explanation of the error) at the beginning,
so that it is not cut by truncation if the query is very long (which happens if the query goes first).
