|
MySQL 5.1.52 リリースノート (日本語翻訳)
修正されたバグ:
・ InnoDB ストレージエンジン : セキュリティ修正 :デバッグバージョンのサーバでは、 TRUNCATETABLE を発行し、同時に INFORMATION_SCHEMA データベースでそれと同じテーブルの情報を調査すると、クラッシュする可能性があった( Bug#54678 )。
・ セキュリティ修正 : Geometry 以外のタイプの値をタイプ GeometryCollection ( MultiPoint 、 MultiCurve 、 MultiSurface )の項目に代入すると、サーバがクラッシュした。現在はサーバがフィールドのタイプをチェックして、不正なパラメータを検出すると、 badgeometryvalue で失敗する( Bug#55531 )。
・ セキュリティ修正 : EXPLAINEXTENDED によって、一部のプリペアドステートメントでサーバがクラッシュした( Bug#54494 )。
・ セキュリティ修正 :プリペアドステートメントモードで、派生テーブルからの SELECT の EXPLAIN でサーバがクラッシュした( Bug#54488 )。
・ InnoDB ストレージエンジン : LOCKTABLES ステートメントと UNLOCKTABLES ステートメントが同時に大量に実行されると、サーバがクラッシュした( Bug#57345 )。
・ InnoDB ストレージエンジン :カスケードしている外部キー制約によって削除された行数が250を超えた場合、 InnoDB が正しくないエラーをレポートした( Bug#57255 )。
・ InnoDB ストレージエンジン :デバッグバージョンのサーバでは、 InnoDB テーブルの行の範囲に影響を与える SELECT...FORUPDATE ステートメントによって、クラッシュする可能性があった( Bug#56716 )。
・ InnoDB ストレージエンジン :インデックス付きでないカラムだけが変更された場合の InnoDB テーブルに対する UPDATE 操作のパフォーマンスが向上した( Bug#56340 )。
・ InnoDB ストレージエンジン : --innodb-use-system-malloc=0 を指定して起動されていたサーバが、シャットダウン時にクラッシュする可能性があった( Bug#55627 )。
・ InnoDB ストレージエンジン :自動増分カラムが存在する InnoDB テーブルを、サーバの再起動後に最初に参照するステートメントが SHOWCREATETABLE ステートメントである場合、サーバがクラッシュする可能性があった( Bug#55277 )。
・ InnoDB ストレージエンジン : InnoDB テーブルに PACK_KEYS=0 テーブルオプションを設定すると、テーブルに新しいインデックスを追加できなかった( Bug#54606 )。
・ InnoDB ストレージエンジン : ROLLBACK 操作中の InnoDB データディクショナリのロックメカニズムを変更して、 REPLACE ステートメントの同時性を改善した( Bug#54538 )。
・ InnoDB ストレージエンジン : InnoDB テーブルに対して ALTERTABLE...ADDPRIMARYKEY を実行した後またはテーブル全体のコピーを行う他の何らかの操作を実行した後に、サーバがクラッシュし、それを再起動した場合、リカバリ中に InnoDB トランザクションが、後退復帰ではなく、誤ってコミットされる可能性があった( Bug#53756 )。
・ パーティショニング : レプリケーション :ステートメントベースのログモードを使用しているときに、 MyISAM パーティションドテーブルに対して LOADDATA を実行しようとすると、マスタがハングまたはクラッシュした( Bug#51851 )。
・ パーティショニング :マルチテーブル UPDATE ステートメントに MyISAM パーティションドテーブルが含まれる場合、そのテーブルが破損する可能性があった。この問題を調べるには、その UPDATE の影響を受けるすべてのテーブルをパーティショニングする必要はなかった( Bug#55458 )。
・ パーティショニング : EXPLAINPARTITIONS が、 MyISAM パーティションドテーブルに対する範囲クエリについて不正な見積もりを返した。また、 EXPLAINPARTITIONS の出力の rows カラムの値にパーティションの取り除きが考慮されていなかった( Bug#53806 、 Bug#46754 )。
・ レプリケーション :セーブポイントの識別子を囲むバッククォートがバイナリログでは失われていたので、バッククォートのない識別子が誤って解釈されて構文エラーまたはその他のエラーが発生する可能性がある場合にレプリケーションが失敗する可能性があった。
さらに、生成されたセーブポイントIDを使用するMySQLアプリケーションプログラムに問題が発生する可能性があった。たとえば、 java.sql.Connection.setSavepoint() がパラメータなしで呼び出された場合、Connector/Jは自動的にバッククォート( ` )文字で囲まれた16進数 0 〜 F の文字列で構成されるセーブポイント識別子を生成する。そのような識別子の形式が ` N e N ` ( N は10進数 0 〜 9 の文字列、 e は大文字または小文字の「E」)だった場合、識別子がバイナリログに書き込まれたときにバッククォートが削除されて残された従属文字列は、スレーブMySQLサーバによって識別子ではなく浮動小数点数と解釈された。その結果、構文エラーが発生し、レプリケーションが失われた( Bug#55961 )。
Bug#55962 も参照。
・ Windows上で mysqld がサービスとして起動され、 mysqld がファイルにエラーログを書き込んでいる場合(たとえば --log-error オプション付きで起動されていた場合)、サーバは stdout と stderr の各ストリームのファイル記述子をログファイルのファイル記述子に再割り当てする。Windowsでは、 stdout または stderr が出力ストリームに関連付けられていない場合、ファイル記述子は負値を返す。以前は、これによってファイル記述子の再割り当てが失敗し、サーバが中断していた。Windows上でこの問題を回避するために、現在は stdout と stderr の各ストリームはまずログファイルをオープンすることによってログファイルストリームに割り当てられる。これによって stdout と stderr の各ファイル記述子は0以外の値となり、サーバは正常にログファイルのファイル記述子にそれらを再割り当てできる( Bug#56821 )。
・ Valgrindによって検出されたメモリリークは修正された( Bug#56709 )。
・ クエリで 'YYYY-MM-DDHH:MM:SS' 以外の形式で DATE または DATETIME の値が指定された場合、「より多いか等しい」( >= )条件がインデックス付きの TIMESTAMP カラムの「より多い」値にのみ一致していた( Bug#55779 )。
・ 有効な SELECT ステートメントが存在する場合、トリガの実行中にエラーが生成されると、サーバがクラッシュする可能性があった( Bug#55421 )。
・ テンポラリテーブルを使用して評価されたサブクエリが含まれる UPDATEIGNORE ステートメントで、テンポラリテーブルからデータを転送する際のエラーが無視され、表明が生成された( Bug#54543 )。
・ 行を生成しない行のサブクエリが、行の比較式で UNKNOWN 値として処理されなかった( Bug#54190 )。
・ MEDIUMBLOB タイプの max_length メタデータ値が、正しい値より1バイト大きい値としてレポートされた( Bug#53296 )。
・ NOTIN サブクエリ述語の左側が行で NULL 値が含まれる場合、クエリの結果が正しくないことがあった( Bug#51070 )。
・ 一部のクエリでは、オプティマイザが、 InnoDB テーブルによるインデックスマージアクセス方法を使用して、正しくない結果を生成していた( Bug#50402 )。
・ インデックススキャンを使用して評価され、計算されたカラムに対する LIMIT 、 GROUPBY 、および ORDERBY を含むクエリに対して、 EXPLAIN が生成する rows 値が正しくなかった( Bug#50394 )。
・ mysql_store_result() と mysql_use_result() はプリペアドステートメントには使用できず、 mysql_stmt_execute() の後に呼び出されることを想定していないが、そのような方法で呼び出された場合、失敗してエラーを返した( Bug#47485 )。
・ MERGE テーブルに対して REPAIRTABLE table USE_FRM を使用すると、サーバがクラッシュした( Bug#46339 )。
・ クエリキャッシュが使用され、接続が切断されるエラーが発生した場合、サーバによって送信されるパケットの形式が不正だった( Bug#42503 )。
・ インデックス定義および外部キー定義で参照されるカラムの定義に大文字と小文字の差がある場合、 CREATETABLE が失敗した( Bug#39932 )。