Well-Known Member
Feb 23, 2002
Several Bugs Read url


D.3.1 Changes in release 4.0.14 (not released yet)
Functionality added or changed:

MySQL now issues a warning (not an error, as in 4.0.13) when it opens a table that was created with MySQL 4.1.
Added option --nice to mysqld_safe to allow setting the niceness of the mysqld process. (Thanks to Christian Hammers for providing the initial patch) (Bug #627)
Added option --read-only to mysqld to only allow updates from slave threads or the SUPER user. (Original patch from Markus Benning).
SHOW BINLOG EVENTS FROM x where x is strictly less than 4 now silently converts x to 4 instead of printing an error. The same change was done for CHANGE MASTER TO MASTER_LOG_POS=x and CHANGE MASTER TO RELAY_LOG_POS=x.
mysqld now only adds an interrupt handler for the SIGINT signal if you start it with the new --gdb option. This is because some MySQL users got strange problems when they accidently send SIGINT to mysqld threads.
RESET SLAVE now clears the Last_errno and Last_error fields in the output of SHOW SLAVE STATUS.
Bugs fixed:

Changed timeout in mysql_real_connect() to use poll() instead of select() to go around problem with many open files in the client.
Fixed wrong results from MATCH ... AGAINST used with a LEFT JOIN query.
Fixed a bug that limited maximal value for mysqld variables in command-line to 4294967295.
Fixed a bug that sometimes caused spurious ``Access denied'' errors in HANDLER ... READ command, when table is referenced via an alias.
Fixed portability problem with safe_malloc, which caused MySQL to give "Freeing wrong aligned pointer" errors on SCO 3.2.
ALTER TABLE ... ENABLE/DISABLE KEYS could cause a core dump when done on an INSERT DELAYED table.
Fixed problem with conversion of localtime to GMT where some times resulted in different (but correct) timestamps. Now MySQL should use the smallest possible timestamp value in this case. (Bug #316)
Very small query cache sizes could crash mysqld. (Bug #549)
Fixed a bug (accidentally introduced by us but limited to version 4.0.13) that made INSERT ... SELECT in an AUTO_INCREMENT column not replicate well. This bug is in the master, not in the slave. (Bug #490)
Fixed a bug: when an INSERT ... SELECT inserted rows into a non-transactional table, but failed at some point (for example because of a 'Duplicate key' error), the query was not written to the binlog; now it is written to the binlog, with its error code, as all other queries are. About the slave-skip-errors option for how to handle partially completed queries in the slave, see section 4.10.6 Replication Options in `my.cnf'. (Bug #491)
SET FOREIGN_KEY_CHECKS=0 was not replicated properly in the MySQL replication. The fix will probably not be backported to 3.23.
On a slave, LOAD DATA INFILE which had no IGNORE or REPLACE clause on the master, was replicated with IGNORE. While this is not a problem if the master's and slave's data are identical (the LOAD having produced no duplicate conflict on the master will not produce any on the slave anyway), which is true in normal operation, it is better for debugging to not silently add the IGNORE (because this way one can get an error message on the slave and discover that for some reason, the data on master and slave are different and investigate why). (Bug #571)
On a slave, LOAD DATA INFILE printed an incomplete ``Duplicate entry '%-.64s' for key %d''' message (the key name and value were not mentioned) in case of duplicate conflict (which does not happen in normal operation). (Bug #573)
When using a slave compiled with --debug, CHANGE MASTER TO RELAY_LOG_POS could cause a debug assertion failure. (Bug #576)
When doing a LOCK TABLES WRITE on an InnoDB table, commit could not happen, if the query was not written to the binary log (for example, if --log-bin was not used, or binlog-ignore-db was used). (Bug #578)
If a 3.23 master had open temporary tables that had been replicated to a 4.0 slave, and the binlog got rotated, these temporary tables were immediately dropped by the slave (which caused problems if the master used them subsequently). This bug had been fixed in 4.0.13, but in a manner which caused an unlikely inconvenience: if the 3.23 master died brutally (power failure), without having enough time to automatically write DROP TABLE statements to its binlog, then the 4.0.13 slave would not notice the temporary tables have to be dropped, until the slave mysqld server is restarted. This minor inconvenience is fixed in 3.23.57 and 4.0.14 (meaning the master must be upgraded to 3.23.57 and the slave to 4.0.14 to remove the inconvenience). (Bug #254)
If MASTER_POS_WAIT() was waiting, and the slave was idle, and the SQL slave thread terminated, MASTER_POS_WAIT() went on waiting forever. Now when the SQL slave thread terminates, MASTER_POS_WAIT() immediately returns NULL (``slave stopped''). Bug 651.
User Comments
Posted by mysqlforum on Friday June 6 2003, @12:40pm [Delete] [Edit]

# Fixed a bug (accidentally introduced by us, only in version 4.0.13) which made INSERT ... SELECT in an auto_increment column not replicate well. This bug is in the master, not in the slave. Bug #490.

This changelog line is kind of misleading. If you have a master->slave set up, running an INSERT ... SELECT will not, in my experience replicate. It will generate a duplicate key error on the slave, because the master will binlog a SET INSERT_ID=##; statement where it doesn't belong, which will lead to the slave stopping when you hit a duplicate key.

cPanel.net Support Ticket Number:
Last edited: