Next | Query returned 80 messages, browsing 61 to 70 | Previous

History of commit frequency

CVS Commit History:


   2012-06-03 00:28:01 by Adam Ciarcinski | Files touched by this commit (3)
Log message:
Changes 5.5.25:
* The --safe-mode server option now is deprecated and will be removed in MySQL
  5.6.
* Performance: InnoDB: Improved the algorithm related to adaptive flushing.
  This fix increases the rate of flushing in cases where compression is used
  and the data set is larger than the buffer pool, leading to eviction.
* InnoDB: In a transaction using the REPEATABLE READ isolation level, an UPDATE
  or DELETE statement for an InnoDB table could sometimes overlook rows
  recently committed by other transactions. As explained in Section 14.3.9.2,
  “Consistent Nonlocking Reads”, DML statements within a REPEATABLE READ
  transaction apply to rows committed by other transactions, even if a query
  could not see those rows.
* InnoDB: The Innodb_buffer_pool_pages_flushed status variable was incorrectly
  set to twice the value it should be. Its value should never exceed the value
  of Innodb_pages_written.
* InnoDB: The error handling and message was improved for attempting to create
  a foreign key with a column referencing itself. The message suggested
  a potential problem with the data dictionary, when no such problem existed.
* InnoDB: The CHECK TABLE statement could fail for a large InnoDB table due to
  a timeout value of 2 hours. For typical storage devices, the issue could
  occur for tables that exceeded approximately 200 or 350 GB, depending on I/O
  speed. The fix relaxes the locking performed on the table being checked,
  which makes the timeout less likely. It also makes InnoDB recognize the
  syntax CHECK TABLE QUICK, which avoids the possibility of the timeout
  entirely.
* Replication: It was theoretically possible for concurrent execution of more
  than one instance of SHOW BINLOG EVENTS to crash the MySQL Server.
* Replication: Statements using AUTO_INCREMENT, LAST_INSERT_ID(), RAND(), or
  user variables could be applied in the wrong context on the slave when using
  statement-based replication and replication filtering server options (see
  Section 16.2.3, “How Servers Evaluate Replication Filtering Rules”).
* Replication: An INSERT into a table that has a composite primary key that
  includes an AUTO_INCREMENT column that is not the first column of this
  composite key is not safe for statement-based binary logging or replication.
  Such statements are now marked as unsafe and fail with an error when using
  the STATEMENT binary logging format. For more information, see Section
  16.1.2.3, “Determination of Safe and Unsafe Statements in Binary \ 
Logging”, as
  well as Section 16.4.1.1, “Replication and AUTO_INCREMENT”.
   2012-05-13 15:05:33 by Takahiro Kambe | Files touched by this commit (3) | Package updated
Log message:
Update mysql55-{client,server} to 5.55.24.

Changes (http://dev.mysql.com/doc/refman/5.5/en/news-5-5-24.html):

Functionality Added or Changed

    * Important Change: Replication: INSERT ON DUPLICATE KEY UPDATE is now
      marked as unsafe for statement-based replication if the target table has
      more than one primary or unique key. For more information, see Section
      16.1.2.3, "Determination of Safe and Unsafe Statements in Binary
      Logging".

Bugs Fixed

    * Security Fix: Bug #64884 was fixed.

    * InnoDB: Replication: When binary log statements were replayed on the
      slave, the Com_insert, Com_update, and Com_delete counters were
      incremented by BEGIN statements initiating transactions affecting InnoDB
      tables but not by COMMIT statements ending such transactions. This
      affected these statements whether they were replicated or they were run
      using mysqlbinlog. (Bug #12662190)

    * If the --bind-address option was given a host name value and the host
      name resolved to more than one IP address, the server failed to
      start. For example, with --bind-address=localhost, if localhost resolved
      to both 127.0.0.1 and ::1, startup failed. Now the server prefers the
      IPv4 address in such cases. (Bug #61713, Bug #12762885)

    * mysql_store_result() and mysql_use_result() are not for use with
      prepared statements and are not intended to be called following
      mysql_stmt_execute(), but failed to return an error when invoked that
      way in libmysqld. (Bug #62136, Bug #13738989)

      References: See also Bug #47485.

    * On Windows, mysqlslap crashed for attempts to connect using shared
      memory. (Bug #31173, Bug #11747181, Bug #59107, Bug #11766072)
   2012-04-14 14:10:05 by Adam Ciarcinski | Files touched by this commit (3)
Log message:
Changes 5.5.23:
Bugs Fixed
* Security Fix: Bug 59533 was fixed.
* Performance: Partitioning: InnoDB Storage Engine: The statistics used by the
  optimizer for queries against partitioned InnoDB tables were based only on the
  first partition of each such table, leading to use of the wrong execution
  plan.
* References: This bug was introduced by Bug 11756867.
* Performance: InnoDB Storage Engine: Improved the performance of the DROP TABLE
  statement for InnoDB tables, especially on systems with a large buffer pool.
  The fix speeds up the processing for freeing entries in the adaptive hash
  index.
* InnoDB Storage Engine: Deleting a huge amount of data from InnoDB tables
  within a short time could cause the purge operation that flushes data from the
  buffer pool to stall. If this issue occurs, restart the server to work around
  it. This issue is only likely to occur on 32-bit platforms.
* InnoDB Storage Engine: If the server crashed during a TRUNCATE TABLE or CREATE
  INDEX statement for an InnoDB table, or a DROP DATABASE statement for
  a database containing InnoDB tables, an index could be corrupted, causing an
  error message when accessing the table after restart:
  InnoDB: Error: trying to load index index_name for table table_name
  InnoDB: but the index tree has been freed!
  In MySQL 5.1, this fix applies to the InnoDB Plugin, but not the built-in
  InnoDB storage engine.
* InnoDB Storage Engine: When data was removed from an InnoDB table, newly
  inserted data might not reuse the freed disk blocks, leading to an unexpected
  size increase for the system tablespace or .ibd file (depending on the
  setting of innodb_file_per_table. The OPTIMIZE TABLE could compact a .ibd file
  in some cases but not others. The freed disk blocks would eventually be
  reused as additional data was inserted.
More...
   2012-04-08 20:30:27 by Adam Ciarcinski | Files touched by this commit (3) | Package updated
Log message:
Changes 5.5.22:
* InnoDB Storage Engine: A deprecation warning is now issued when
  --ignore-builtin-innodb is used.
* yaSSL was upgraded from version 1.7.2 to 2.2.0.
* Security Fix: Bug 13510739 and Bug 63775 were fixed.
* Important Change: InnoDB Storage Engine: When a row grew in size due to an
  UPDATE operation, other (non-updated) columns could be moved to off-page
  storage so that information about the row still fit within the constraints of
  the InnoDB page size. The pointer to the new allocated off-page data was not
  set up until the pages were allocated and written, potentially leading to
  lost data if the system crashed while the column was being moved out of the
  page. The problem was more common with tables using ROW_FORMAT=DYNAMIC or
  ROW_FORMAT=COMPRESSED along with the Barracuda file format, particularly with
  the innodb_file_per_table setting enabled, because page allocation operations
  are more common as the .ibd tablespace files are extended. Still, the problem
  could occur with any combination of InnoDB version, file format, and row
  format.
* InnoDB Storage Engine: An erroneous assertion could occur, in debug builds
  only, when creating an index on a column containing zero-length values (that
  is, '').
* InnoDB Storage Engine: A DDL operation such as ALTER TABLE ... ADD COLUMN
  could stall, eventually timing out with an Error 1005: Can't create table
  message referring to fil_rename_tablespace.
* InnoDB Storage Engine: A DDL operation for an InnoDB table could cause a busy
  MySQL server to halt with an assertion error:
More...
   2012-02-23 14:01:03 by Adam Ciarcinski | Files touched by this commit (3)
Log message:
Changes 5.5.21:
* A new CMake option, MYSQL_PROJECT_NAME, can be set on Windows or Mac OS X to
  be used in the project name.
Bugs Fixed
* Performance: InnoDB Storage Engine: Memory allocation for InnoDB tables was
  reorganized to reduce the memory overhead for large numbers of tables or
  partitions, avoiding situations where the “resident set size” could grow
  regardless of FLUSH TABLES statements. The problem was most evident for tables
  with large row size.
* Incompatible Change: An earlier change (in MySQL 5.1.62 and 5.5.21) was found
  to modify date-handling behavior in General Availability-status series (MySQL
  5.1 and 5.5). This change has been reverted.
* The change was that several functions became more strict when passed a DATE()
  function value as their argument, thus they rejected incomplete dates with
  a day part of zero. These functions were affected: CONVERT_TZ(), DATE_ADD(),
  DATE_SUB(), DAYOFYEAR(), LAST_DAY(), TIMESTAMPDIFF(), TO_DAYS(), TO_SECONDS(),
  WEEK(), WEEKDAY(), WEEKOFYEAR(), YEARWEEK(). The previous behavior has been
  restored.
* InnoDB Storage Engine: A Valgrind error was fixed in the function
  os_aio_init().
* InnoDB Storage Engine: The server could crash when creating an InnoDB
  temporary table under Linux, if the $TMPDIR setting points to a tmpfs
  filesystem and innodb_use_native_aio is enabled, as it is by default in MySQL
  5.5.4 and higher.
* InnoDB Storage Engine: References to C preprocessor symbols and macros
  HAVE_purify, UNIV_INIT_MEM_TO_ZERO, and UNIV_SET_MEM_TO_ZERO were removed
  from the InnoDB source code. They were only used in debug builds instrumented
  for Valgrind. They are replaced by calls to the UNIV_MEM_INVALID() macro.
   2012-02-16 15:47:01 by Takahiro Kambe | Files touched by this commit (1)
Log message:
Sort PLIST.
   2012-01-12 17:33:49 by Adam Ciarcinski | Files touched by this commit (3) | Package updated
Log message:
Changes 5.5.20:
* A new server option, --slow-start-timeout, controls the Windows service
  control manager's service start timeout. The value is the maximum number of
  milliseconds that the service control manager waits before trying to kill the
  MySQL service during startup. The default value is 15000 (15 seconds). If the
  MySQL service takes too long to start, you may need to increase this value.
  A value of 0 means there is no timeout.

Bugs Fixed:
* Important Change: Replication: Setting an empty user in a CHANGE MASTER TO
  statement caused an invalid internal result and is no longer permitted. Trying \ 
 to use MASTER_USER='' or setting MASTER_PASSWORD while leaving MASTER_USER
  unset causes the statement to fail with an error.
* Important Change: Replication: Moving the binary log file, relay log file, or
  both files to a new location, then restarting the server with a new value for
  --log-bin, --relay-log, or both, caused the server to abort on start. This
  was because the entries in the index file overrode the new location. In
  addition, paths were calculated relative to datadir (rather than to the
  --log-bin or --relay-log values).
* InnoDB Storage Engine: When doing a live downgrade from MySQL 5.6.4 or later,  \ 
 with innodb_page_size set to a value other than 16384, now the earlier MySQL
  version reports that the page size is incompatible with the older version,
  rather than crashing or displaying a “corruption” error.
* InnoDB Storage Engine: Issuing INSERT...ON DUPLICATE KEY statements for
  InnoDB tables from concurrent threads could cause a deadlock, particularly
  with the INSERT...ON DUPLICATE KEY UPDATE form. The fix avoids deadlocks
  caused by the same row being accessed by more than one transaction. Deadlocks
  could still occur when multiple rows are inserted and updated simultaneously
  by different transactions in inconsistent order; those types of deadlocks
  require the standard error handling on the application side, of re-trying the
  transaction.
* An incorrect InnoDB assertion could cause the server to halt. This issue only
  affected debug builds. The assertion referenced the source file btr0pcur.ic
  and the variable cursor->pos_state.
* Locale information for FORMAT() function instances was lost in view
  definitions.
* The handle_segfault() signal-handler code in mysqld could itself crash due to
  calling unsafe functions.
* Enabling myisam_use_mmap could cause the server to crash.
* Concurrent access to ARCHIVE tables could cause corruption.
   2011-12-13 13:14:49 by Adam Ciarcinski | Files touched by this commit (3)
Log message:
Changes 5.5.19:
* Performance of metadata locking operations on Windows XP systems was improved
  by instituting a cache for metadata lock objects. This permits the server to
  avoid expensive operations for creation and destruction of synchronization
  objects on XP. A new system variable, metadata_locks_cache_size, permits
  control over the size of the cache. The default size is 1024.
* Replication: Previously, replication slaves could connect to the master
  server through master accounts that use nonnative authentication, except
  Windows native authentication. This is now also true for Windows native
  authentication.

Bugs Fixed:
* InnoDB Storage Engine: An internal deadlock could occur within InnoDB, on
  a server doing a substantial amount of change buffering for DML operations,
  particularly DELETE statements.
* Rounding DBL_MAX returned DBL_MAX, not 'inf'.
* mysql_upgrade did not upgrade the system tables or create the
  mysql_upgrade_info file when run with the --write-binlog or
  --skip-write-binlog option.
* If a plugin was uninstalled, thread local variables for plugin variables of
  string type with wth PLUGIN_VAR_MEMALLOC flag were not freed.
* Deadlock could occur when these four things happened at the same time: 1) An
  old dump thread was waiting for the binary log to grow. 2) The slave server
  that replicates from the old dump thread tried to reconnect. During
  reconnection, the new dump thread tried to kill the old dump thread.
  3) A KILL statement tried to kill the old dump thread. 4) An INSERT statement
  caused a binary log rotation.
   2011-11-21 17:55:59 by Adam Ciarcinski | Files touched by this commit (3)
Log message:
Changes 5.5.18:

Functionality Added or Changed
* Upgrading from an Advanced GPL RPM package to an Advanced RPM package did not
  work. Now on Linux it is possible to use rpm -U to replace any installed
  MySQL product by any other of the same release family. It is not necessary to
  remove the old produce with rpm -e first.

Bugs Fixed
* Incompatible Change: Replication.
* During the table-opening process, memory was allocated and later freed that
  was needed view loading, even for statements that did not use views. These
  unnecessary allocation and free operations are no longer done.
* mysql_plugin mishandled the --plugin-ini, --mysqld, and --my-print-defaults
  options under some circumstances.
* mysql_plugin returned the wrong error code from failed server bootstrap
  execution.
* Several improvements were made to the libedit library bundled with MySQL
  distributions, and that is available for all platforms that MySQL supports
  except Windows.
* ARCHIVE tables with NULL columns could cause server crashes or become corrupt
  under concurrent load.
* OPTIMIZE TABLE could corrupt MyISAM tables if myisam_use_mmap was enabled.
* A query that selected a GROUP_CONCAT() function result could return different
  values depending on whether an ORDER BY of the function result was present.
* For FEDERATED tables, loss of connection to the remote table during some
  insert operations could cause a server crash.
   2011-10-22 12:32:37 by Adam Ciarcinski | Files touched by this commit (4) | Package updated
Log message:
Changes 5.5.17:
* Replication: Previously, replication slaves could connect to the master
  server only through master accounts that use native authentication. Now
  replication slaves can also connect through master accounts that use
  nonnative authentication (except Windows native authentication) if the
  required client-side plugin is installed on the slave side in the directory
  named by the slave plugin_dir system variable.
* MEMORY table creation time is now available in the CREATE_TIME column of the
  INFORMATION_SCHEMA.TABLES table and the Create_time column of SHOW TABLE
  STATUS output.
* InnoDB Storage Engine: This fix improves the performance of instrumentation
  code for InnoDB buffer pool operations.
* InnoDB Storage Engine: Data from BLOB columns could be lost if the server
  crashed at a precise moment when other columns were being updated in an
  InnoDB table.
* InnoDB Storage Engine: Lookups using secondary indexes could give incorrect
  matches under a specific set of conditions. The conditions involve an index
  defined on a column prefix, for a BLOB or other long column stored outside
  the index page, with a table using the Barracuda file format.
* InnoDB Storage Engine: This fix corrects cases where the MySQL server could
  hang or abort with a long semaphore wait message. (This is a different issue
  than when these symptoms occurred during a CHECK TABLE statement.)
* Internal conversion of zero to binary and back could yield a result with
  incorrect precision.
* Valgrind warnings generated by filesort operations were fixed.
* mysqld_safe did not properly check for an already running instance of mysqld.
* The help message for mysql_install_db did not indicate that it supports the
  --defaults-file, --defaults-extra-file and --no-defaults options.
* An assertion designed to detect zero-length sort keys also was raised when
  the entire key set fit in memory.
* myisampack could create corrupt FULLTEXT indexes when compressing tables.
* A linking problem prevented the FEDERATED storage engine plugin from loading.

Next | Query returned 80 messages, browsing 61 to 70 | Previous