MySQL's HOMEPAGE: www.mysql.com
MySQL's TYPE: (Open Source)
MySQL's DOWNLOAD: MySQL 5.1.43
MySQL's SIZE: 39.01 MB
MySQL's GOOGLE HITS: 22 Millions +
MySQL delivers enterprise features, including:
- Partitioning to improve performance and management of very large database environments
- Row-based/Hybrid Replication for improved replication security
- Event Scheduler to create and schedule jobs that perform various database tasks
- XPath Support
- Dynamic General/Slow Query Log
- Performance/Load Testing Utility (mysqlslap)
- Improved! Full Text Search (faster, new dev templates)
- Improved! Archive engine (better compression, more features)
- Improved! User session and problem SQL identification
- Improved! MySQL embedded library (libmysqld)
- Additional INFORMATION_SCHEMA objects
- Faster data import operations (parallel file load)
- ACID Transactions to build reliable and secure business critical applications
- Stored Procedures to improve developer productivity
- Triggers to enforce complex business rules at the database level
- Views to ensure sensitive information is not compromised
- Information Schema to provide easy access to metadata
- Pluggable Storage Engine Architecture for maximum flexibility
- Archive Storage Engine for historical and audit data
MySQL 5.1.43 Improvements:
# Bugs fixed:* Security Fix: For servers built with yaSSL, a preauthorization buffer overflow could cause memory corruption or a server crash. We thank Evgeny Legerov from Intevydis for providing us with a proof-of-concept script that allowed us to reproduce this bug. (Bug#50227, CVE-2009-4484)
* Important Change: Replication: The RAND() function is now marked as unsafe for statement-based replication. Using this function now generates a warning when binlog_format=STATEMENT and causes the the format to switch to row-based logging when binlog_format=MIXED.
This change is being introduced because, when RAND() was logged in statement mode, the seed was also written to the binary log, so the replication slave generated the same sequence of random numbers as was generated on the master. While this could make replication work in some cases, the order of affected rows was still not guaranteed when this function was used in statements that could update multiple rows, such as UPDATE or INSERT ... SELECT; if the master and the slave retrieved rows in different order, they began to diverge. (Bug#49222)
* Partitioning: When used on partitioned tables, the records_in_range handler call checked all partitions, rather than the unpruned partitions only. (Bug#48846) See also Bug#37252, Bug#47261.
* Partitioning: A query that searched on a ucs2 column failed if the table was partitioned. (Bug#48737)
* Replication: A LOAD DATA INFILE statement that loaded data into a table having a column name that must be escaped (such as `key` INT), caused replication to fail when logging in mixed or statement mode. In such cases, the master wrote the LOAD DATA event to the binary log without escaping the field names. (Bug#49473) See also Bug#47927.
* Replication: Spatial data types cause row-based replication to crash. (Bug#48776)
* Replication: A flaw in the implementation of the purging of binary logs could result in orphaned files being left behind in the following circumstances:
- If the server failed or was killed while purging binary logs.
- If the server failed or was killed after creating of a new binary log when the new log file was opened for the first time.
In addition, if the slave was not connected during the purge operation, it was possible for a log file that was in use to be removed; this could lead data loss and possible inconsistencies between the master and slave. (Bug#45292)
* Replication: When using the STATEMENT or MIXED logging format, the statements LOAD DATA CONCURRENT LOCAL INFILE and LOAD DATA CONCURRENT INFILE were logged as LOAD DATA LOCAL INFILE and LOAD DATA LOCAL INFILE, respectively (in other words, the CONCURRENT keyword was omitted). As a result, when using replication with either of these logging modes, queries on the slaves were blocked by the replication SQL thread while trying to execute the affected statements. (Bug#34628)
* Replication: Manually removing entries from the binary log index file on a replication master could cause the server to repeatedly send the same binary log file to slaves. (Bug#28421)
* Cluster Replication: When expire_logs_days was set, the thread performing the purge of the log files could deadlock, causing all binary log operations to stop. (Bug#49536)
* Within a stored routine, selecting the result of CONCAT_WS() with a routine parameter argument into a user variable could return incorrect results. (Bug#50096)
* The IBMDB2I storage engine was missing from the i5os 64-bit distribution of MySQL 5.1.42. It is now included again. (Bug#50059)
* EXPLAIN EXTENDED UNION ... ORDER BY caused a crash when the ORDER BY referred to a nonconstant or full-text function or a subquery. (Bug#49734)
* The push_warning_printf() function was being called with an invalid error level MYSQL_ERROR::WARN_LEVEL_ERROR, causing an assertion failure. To fix the problem, MYSQL_ERROR::WARN_LEVEL_ERROR has been replaced by MYSQL_ERROR::WARN_LEVEL_WARN. (Bug#49638)
* Some prepared statements could raise an assertion when re-executed. (Bug#49570)
* A Valgrind error in make_cond_for_table_from_pred() was corrected. Thanks to Sergey Petrunya for the patch to fix this bug. (Bug#49506)
* When compiling on Windows, an error in the CMake definitions for InnoDB would cause the engine to be built incorrectly. (Bug#49502)
* Valgrind warnings for CHECKSUM TABLE were corrected. (Bug#49465)
* Specifying an index algorithm (such as BTREE) for SPATIAL or FULLTEXT indexes caused a server crash. These index types do not support algorithm specification, and it is now disallowed to do so. (Bug#49250)
* The optimizer sometimes incorrectly handled conditions of the form WHERE col_name='const1' AND col_name='const2'. (Bug#49199)
* Execution of DECODE() and ENCODE() could be inefficient because multiple executions within a single statement reinitialized the random generator multiple times even with constant parameters. (Bug#49141)
* MySQL 5.1 does not support 2-byte collation numbers, but did not check the number and crashed for out-of-range values. (Bug#49134)
* With binary logging enabled, REVOKE ... ON {PROCEDURE|FUNCTION} FROM ... could cause a crash. (Bug#49119)
* The LIKE operator did not work correctly when using an index for a ucs2 column. (Bug#49028)
* check_key_in_view() was missing a DBUG_RETURN in one code branch, causing a crash in debug builds. (Bug#48995)
* Several strmake() calls had an incorrect length argument (too large by one). (Bug#48983)
* On Fedora 12, strmov() did not guarantee correct operation for overlapping source and destination buffer. Calls were fixed to use an overlap-safe version instead. (Bug#48866)
* Incomplete reset of internal TABLE structures could cause a crash with eq_ref table access in subqueries. (Bug#48709)
* Re-execution of a prepared statement could cause a server crash. (Bug#48508)
* The error message for ER_UPDATE_INFO was subject to buffer overflow or truncation. (Bug#48500)
* SHOW BINLOG EVENTS could fail with a error: Wrong offset or I/O error. (Bug#48357)
* Valgrind warnings related to binary logging of LOAD DATA INFILE statements were corrected. (Bug#48340)
* An aliasing violation in the C API could lead to a crash. (Bug#48284)
* The InnoDB Monitor could fail to print diagnostic information after a long lock wait. (Bug#47814)
* Queries containing GROUP BY ... WITH ROLLUP that did not use indexes could return incorrect results. (Bug#47650)
* If an invocation of a stored procedure failed in the table-open stage, subsequent invocations that did not fail in that stage could cause a crash. (Bug#47649)
* On Solaris, no stack trace was printed to the error log after a crash. (Bug#47391)
* The first execution of STOP SLAVE UNTIL stopped too early. (Bug#47210)
* When the mysql client was invoked with the --vertical option, it ignored the --skip-column-names option. (Bug#47147)
* It was possible for init_available_charsets() not to initialize correctly. (Bug#45058)
* Comparison with NULL values sometimes did not produce a correct result. (Bug#42760)
* Crash recovery did not work for InnoDB temporary tables. (Bug#41609)
* The mysql_upgrade command would create three additional fields to the mysql.proc table (character_set_client, collation_connection, and db_collation), but did not populate the fields with correct values. This would lead to error messages reported during stored procedure execution. (Bug#41569)
* When compressed MyISAM files were opened, they were always memory mapped, sometimes causing memory-swapping problems. To deal with this, a new system variable, myisam_mmap_size, was added to limit the amount of memory used for memory mapping of MyISAM files. (Bug#37408)
* A race condition on the privilege hash tables allowed one thread to try to delete elements that had already been deleted by another thread. A consequence was that SET PASSWORD or FLUSH PRIVILEGES could cause a crash. (Bug#35589, Bug#35591)
* ALTER TABLE with both DROP COLUMN and ADD COLUMN clauses could crash or lock up the server. (Bug#31145)
* Performance: When the query cache is fragmented, the size of the free block lists in the memory bins grows, which causes query cache invalidation to become slow. There is now a 50ms timeout for a SELECT statement waiting for the query cache lock. If the timeout expires, the statement executes without using the query cache. (Bug#39253)
* Important Change: Replication: The following functions have been marked unsafe for statement-based replication:
- GET_LOCK()
- IS_FREE_LOCK()
- IS_USED_LOCK()
- MASTER_POS_WAIT()
- RELEASE_LOCK()
- SLEEP()
- SYSDATE()
- VERSION()
None of the functions just listed are guaranteed to replicate correctly when using the statement-based format, because they can produce different results on the master and the slave. The use of any of these functions while binlog_format is set to STATEMENT is logged with the warning, Statement is not safe to log in statement format. When binlog_format is set to MIXED, the binary logging format is automatically switched to the row-based format whenever one of these functions is used. (Bug#47995)
* Partitioning: In some cases, it was not possible to add a new column to a table that had subpartitions. (Bug#48276)
* Partitioning: SELECT COUNT(*) from a partitioned table failed when using the ONLY_FULL_GROUP_BY SQL mode. (Bug#46923)
This regression was introduced by Bug#45807.
* Partitioning: SUBPARTITION BY KEY failed with DEFAULT CHARSET=utf8. (Bug#45904)
* Replication: When using row-based logging, TRUNCATE TABLE was written to the binary log even if the affected table was temporary, causing replication to fail. (Bug#48350)
* Replication: Replicating TEXT or VARCHAR columns declared as NULL on the master but NOT NULL on the slave caused the slave to crash. (Bug#43789)
See also Bug#38850, Bug#43783, Bug#43785, Bug#47741, Bug#48091.
* Replication: When using row-based format, replication failed with the error Could not execute Write_rows event on table ...; Field '...' doesn't have a default value when an INSERT was made on the master without specifying a value for a column having no default, even if strict server SQL mode was not in use and the statement would otherwise have succeeded on the master. Now the SQL mode is checked, and the statement is replicated unless strict mode is in effect. For more information, see Section 5.1.8, “Server SQL Modes”. (Bug#38173)
See also Bug#38262, Bug#43992.
* The result of comparison between nullable BIGINT and INT columns was inconsistent. (Bug#49517)
* Incorrect cache initialization prevented storage of converted constant values and could produce incorrect comparison results. (Bug#49489)
* Comparisons involving YEAR values could produce incorrect results. (Bug#49480) See also Bug#43668.
* InnoDB did not reset table AUTO_INCREMENT values to the last used values after a server restart. (Bug#49032)
* If a query involving a table was terminated with KILL, a subsequent SHOW CREATE TABLE for that table caused a server crash. (Bug#48985)
* Privileges for stored routines were ignored for mixed-case routine names. (Bug#48872) See also Bug#41049.
* Building MySQL on Fedora Core 12 64-bit would due to errors in comp_err. (Bug#48864)
* Concurrent ALTER TABLE operations on an InnoDB table could raise an assertion. (Bug#48782)
* During query execution, ranges could be merged incorrectly for OR operations and return an incorrect result. (Bug#48665)
* The InnoDB Table Monitor reported the FLOAT and DOUBLE data types incorrectly. (Bug#48526)
* With row-based binary logging, the server crashed for statements of the form CREATE TABLE IF NOT EXISTS existing_view LIKE temporary_table. This occurred because the server handled the existing view as a table when logging the statement. (Bug#48506)
* DISTINCT was ignored for queries with GROUP BY WITH ROLLUP and only const tables. (Bug#48475)
* Loose index scan was inappropriately chosen for some WHERE conditions. (Bug#48472)
* If the InnoDB tablespace was configured with too small a value, the server could crash and corrupt the tablespace. (Bug#48469)
* Parts of the range optimizer could be initialized incorrectly, resulting in Valgrind errors. (Bug#48459)
* A bad typecast could cause query execution to allocate large amounts of memory. (Bug#48458)
* On Windows, InnoDB could not be built as a statically linked library. (Bug#48317)
* mysql_secure_installation did not work on Solaris. (Bug#48086)
* When running mysql_secure_installation, the command would fail if the root password contained multiple spaces, \, # or quote characters. (Bug#48031)
* MATCH IN BOOLEAN MODE searches could return too many results inside a subquery. (Bug#47930)
* Using REPLACE to update a previously inserted negative value in an AUTO_INCREMENT coumn in an InnoDB table caused the table auto-increment value to be updated to 2147483647. (Bug#47720)
* If a session held a global read lock acquired with FLUSH TABLES WITH READ LOCK, a lock for one table acquired with LOCK TABLES, and issued an INSERT DELAYED statement for another table, deadlock could occur. (Bug#47682)
* The mysql client status command displayed an incorrect value for the server character set. (Bug#47671)
* Connecting to a 4.1.x server from a 5.1.x or higher mysql client resulted in a memory-free error when disconnecting. (Bug#47655)
* Assignment of a system variable sharing the same base name as a declared stored program variable in the same context could lead to a crash. (Bug#47627)
* The innodb_file_format_check system variable could not be set at runtime to DEFAULT or to the value of a user-defined variable. (Bug#47167)
* After a binary upgrade to MySQL 5.1 from a MySQL 5.0 installation that contains ARCHIVE tables, accessing those tables caused the server to crash, even if you had run mysql_upgrade or CHECK TABLE ... FOR UPGRADE.
To work around this problem, use mysqldump to dump all ARCHIVE tables before upgrading, and reload them into MySQL 5.1 after upgrading. The same problem occurs for binary downgrades from MySQL 5.1 to 5.0. (Bug#47012)
* The IGNORE clause on a DELETE statement masked an SQL statement error that occurred during trigger processing. (Bug#46425)
* On 64-bit systems, --skip-innodb did not skip InnoDB startup. (Bug#46043)
* Valgrind errors for InnoDB Plugin were corrected. (Bug#45992, Bug#46656)
* The return value was not checked for some my_hash_insert() calls. (Bug#45613)
* Truncation of DECIMAL values could lead to assertion failures; for example, when deducing the type of a table column from a literal DECIMAL value. (Bug#45261) See also Bug#48370.
* For YEAR(2) values, MIN(), MAX(), and comparisons could yield incorrect results. (Bug#43668)
* The server could crash when attempting to access a non-conformant mysql.proc system table. For example, the server could crash when invoking stored procedure-related statements after an upgrade from MySQL 5.0 to 5.1 without running mysql_upgrade. (Bug#41726)
* Use of InnoDB monitoring (SHOW ENGINE INNODB STATUS or one of the InnoDB Monitor tables) could cause a server crash due to invalid access to a shared variable in a concurrent environment. This is a further fix for a regression introduced in MySQL 5.1.38 to the original fix in MySQL 5.1.31. (Bug#38883)
* When running mysql_secure_installation on Windows, the command would fail to load a required module, Term::ReadKey, which was required for correct operation. (Bug#35106)
* If the --log-bin server option was set to a directory name with a trailing component separator character, the basename of the binary log files was empty so that the created files were named .000001 and .index. The same thing occurred with the --log-bin-index, --relay-log, and --relay-log-index options. Now the server reports and error and exits. (Bug#34739)
* If a comparison involved a constant value that required type conversion, the converted value might not be cached, resulting in repeated conversion and poorer performance. (Bug#34384)
* Using the SHOW ENGINE INNODB STATUS statement when using partitions in InnoDB tables caused Invalid (old?) table or database name errors to be logged. (Bug#32430)
* On some Windows systems, InnoDB could report Operating system error number 995 in a file operation due to transient driver or hardware problems. InnoDB now retries the operation and adds Retry attempt is made to the error message. (Bug#3139)
0 comments:
Post a Comment