オープンソース サポート サービス(OSS サポート サービス)| オープンソースまるごと OpenStandia™(オープンスタンディア)
野村総合研究所


MySQL 5.1.33 リリースノート (日本語翻訳)

 

機能の追加と変更:

・ mysql-test-run.pl は、 --experimental= file_name オプションをサポートするようになった。これにより、失敗した場合に [fail] ではなく [exp-fail] コードを使って表示する必要があるテストケースのリストを含んだファイルを指定できる( Bug#42888 )。

・MD5アルゴリズムは、Xfree実装を使用するようになった( Bug#42434 )。

・クエリキャッシュは、 SELECT ステートメントが SQL_NO_CACHE で始まるかどうかをチェックして、クエリキャッシュ内のクエリ結果のチェックをスキップできるかどうかを判断するようになった。これは、コメント内に SQL_NO_CACHE が 存在する 場合はサポートされない( Bug#37416 )。

修正されたバグ:

・ パーティショニング : パーティションドテーブルへの挿入時に発生した重複キーエラーでは、パーティションされていないテーブルへの挿入時に発生したエラーによって返されるものとは異なるエラーコードを使用していた( Bug#38719 )。

Bug#28842 も参照。

・ パーティショニング : パーティションドテーブルに関連するエラーメッセージのいくつかは、間違っているか、または欠落していた( Bug#36001 )。

・ レプリケーション : --binlog_format を STATEMENT に設定した場合は、たとえ sql_log_bin を 0 に設定しても、ステートメントベースのログにとって安全でないステートメントによってエラーまたは警告が発行された( Bug#41980 )。

・ レプリケーション : MIXED レプリケーション形式を使用し、テンポラリテーブルがステートメントベースのモードで作成され、同じセッション内の後続の操作によってモードが行ベースに切り替わった場合、スレーブではセッション終了時にテンポラリテーブルが削除されなかった( Bug#40013 )。

Bug#43046 も参照。

この退化は、 Bug#20499 によって導入された。

・ レプリケーション : MIXED レプリケーション形式を使用すると、キーの一部にNULL可能 BIT カラムがある行を検索する UPDATE および DELETE ステートメントが失敗した。データを挿入する操作がステートメントとして複製されたが、同じデータに作用する UPDATE および DELETE ステートメントが行ベースの形式を使用して複製されたために、この問題が発生した。

ステートメントベースのレプリケーションだけを使用するか、行ベースのレプリケーションだけを使用した場合は、この問題は発生しなかった( Bug#39753 )。

Bug#39648 も参照。

・ レプリケーション : ストアドプロシージャの作成時に有効だったサーバ SQL モードは、バイナリログでは保持されなかった。これにより、マスタでは成功した CREATEPROCEDURE ステートメントがスレーブでは失敗する可能性があった。

この問題が最初に認識されたのは、 ANSI_QUOTES がマスタ上で有効な場合にストアドプロシージャを作成したときだった。ただし、他のサーバSQLモードも使用した場合は、この問題によって、 CREATEPROCEDURE ステートメントの失敗や他の問題がスレーブで発生する可能性があった( Bug#39526 )。

・ レプリケーション : --secure-file-priv をスレーブで設定した場合、混合形式またはステートメントベースレプリケーションの使用時には、マスタから送られた LOADDATAINFILE ステートメントを実行できなかった。

この修正の結果、上記のような場合は、スレーブではこのセキュリティ制限が無視されるようになった。代わりにスレーブは、ファイルが作成され、読み取る必要があるかどうかを --slave-load-tmpdir でチェックする( Bug#38174 )。

・ レプリケーション: バイナリログでは、 2147483647(2 32 1) よりも大きいサーバIDが負の数で表されていた( Bug#37313 )。

・ レプリケーション: ディスクが一杯になると、レプリケーションスレーブは、バイナリログ、リレーログ、または MyISAM テーブルの 書き込み中は待機し、スペースが使用可能になってから処理を続行することがある。このような場合に表示されるエラーメッセージは、空きスペースのチェックが行われる頻度(60秒ごとに1回)、およびスペースが解放されてから処理を続行するまでのサーバの待機時間(60秒)に関して明確でなかった。そのため、ユーザはサーバがハングしたと考える可能性があった。

これらの問題は、エラーメッセージをより明確にし、以下の2つの独立したメッセージに分けることによって対処されている。

a.Diskisfullwriting' filename '(Errcode: error_code ).Waitingforsomeonetofreespace...(Expectupto60secsdelayforservertocontinueafterfreeingdiskspace)というエラーメッセージは、1回だけ出力される。

b.Retryin60secs,Messagereprintedin600secsという警告は、空きスペースのチェックが10回実行されるごとに1回出力される。つまり、チェックは60秒ごとに1回実行されるが、スペースの解放が必要であることを伝えるリマインダは10分(600秒)ごとに1回だけ出力される。

( Bug#22082 )

・ レプリケーション : 削除するプロシージャまたは関数が存在しない場合、 DROPPROCEDUREIFEXISTS および DROPFUNCTIONIFEXISTS ステートメントはバイナリログに書き込まれなかった( Bug#13684 )。

Bug#25705 も参照。

・IBMiSeriesプラットフォーム向けのこのリリースには、IBMDB2iストレージエンジンが追加された。詳細については、 セクション13.7「TheIBMDB2IStorageEngine」 を参照( Bug#44217 )。

・64ビットのデバッグビルドでは、64ビットの割り当てに32ビット値を使用したため、 safemalloc のコードによってエラーが発生した( Bug#43885 )。

・ makedistcheck は、 storage/ndb のサブディレクトリを正しく処理できなかった( Bug#43614 )。

・ USEINDEX ヒントを使用すると、 EXPLAINEXTENDED がクラッシュする可能性があった( Bug#43354 )。

・ InnoDB テーブルの場合、 AUTO_INCREMENT カラムでオーバーフローが発生すると、サーバがクラッシュする可能性があった( Bug#43203 )。

・32ビット版のWindowsでは、2GBのユーザモードアドレス制限があるため、 mysqld は大きなバッファを使用できなかった( Bug#43082 )。

・ stderr はバッファなしにする必要があるが、サーバが stderr をファイルにリダイレクトすると、 stderr がバッファ付きになった( Bug#42790 )。

・ INFORMATION_SCHEMA.COLUMNS テーブルの DATA_TYPE カラムでは、浮動小数点データタイプに対して UNSIGNED 属性が表示された(このカラムには、データタイプの名前だけが含まれている必要がある)( Bug#42758 )。

・ InnoDB テーブルの場合、 AUTO_INCREMENT カラムへの挿入時に間違った重複キーエラーが発生する可能性があった( Bug#42714 )。

・ mysqldump には、 --ignore-table オプションによって除外されたビューが含まれていた( Bug#42635 )。

・以前のバグ修正により、組み込み InnoDB を使用してコンパイルされたサーバでは InnoDB プラグインを使用できないという問題が発生した。この問題に対処するため、以下の2つの変更が行われた。

nサーバは、組み込みInnoDBが存在していないかのようにサーバを動作させる --ignore-builtin-innodb オプションをサポートするようになった。このオプションを使用すると、他のInnoDBオプションは認識されない。

n INSTALLPLUGIN ステートメントの場合、サーバはサーバ起動時と同様にオプション( my.cnf )ファイルを読み取る。これにより、プラグインはそれらのファイルから関連オプションをすべて取得することができる。したがって、各オプションがデフォルト値に設定された状態でプラグインが起動されることはなくなる。

この変更が行われたため、プラグインをロードする前でも、プラグインオプションをオプションファイルに追加できる(looseプリフィックスを使用した場合)。また、プラグインをアンインストールし、 my.cnf を編集してから、プラグインを再インストールすることもできる。このようにしてプラグインを再起動すると、サーバを再起動することなく新しいオプション値にすることができる。

注意

バージョン1.0.4以上のInnoDBPluginは、このバグ修正を利用することになる。InnoDBPluginは複数のMySQLリリースと互換性のあるソースコードだが、ある決まったバイナリInnoDBPluginは特定のMySQLリリースでのみ使用できる。InnoDBPlugin1.0.4のリリース時には、MySQL5.1.34用にコンパイルされることが予想される。5.1.33の場合は、InnoDBPlugin1.0.3を使用できるが、ソースからビルドする必要がある。

( Bug#42610 )

この退化は、 Bug#29263 によって導入された。

・ ONLY_FULL_GROUP_BY SQLモードを有効にすると、一部の正当なクエリが失敗した( Bug#42567 )。

・テーブルが正しくクリーンアップされずにスレッドのオープンテーブルのキャッシュに入り、その結果、サーバがクラッシュする可能性があった( Bug#42419 )。

・ InnoDB テーブルの場合、浮動小数点 AUTO_INCREMENT カラムへの挿入が失敗した( Bug#42400 )。

・ InnoDB btr_search_drop_page_hash_when_freed() 関数には競合状態があった( Bug#42279 )。

・ InnoDB テーブルの場合、テーブルのコピーをコミットできるかどうかの定期的なチェック時に ALTERTABLE 、 OPTIMIZETABLE 、 CREATEINDEX 、および DROPINDEX 操作に対する競合状態が生じた( Bug#42152 )。

・ DATETIME 値のマイクロ秒部分(オプション)が許容桁数の6桁より大きくても、マイクロ秒部分の解析は適切に失敗しなかった( Bug#42146 )。

・サーバクラッシュ後の InnoDB リカバリでは、テーブル検索が失敗し、そのテーブル検索によってデータディクショナリのキャッシュが破損する可能性があった( Bug#42075 )。

・ mysqldumpslow は、 --debug および --verbose オプションを正しく解析しなかった( Bug#42027 )。

・ルーズなインデックススキャンアクセスメソッドを使用したクエリは、行を返さない可能性があった( Bug#41610 )。

・サーバクラッシュ後の InnoDB リカバリでは、カラムを NULL から NULL に更新したトランザクションのロールバックを行うと、別のクラッシュが発生する可能性があった( Bug#41571 )。

・長すぎるカラムコメントに関するエラーメッセージは、 Unknownerror という、あまり適切でないメッセージだった ( Bug#41465 )。

・ SELECT* を使用すると、ビューの一部のカラムだけに対する権限を持つユーザはすべてのカラムにアクセスすることができた( Bug#41354 )。

・ MERGE テーブルの基礎となるテーブルにプライマリキーがあり、 MERGE テーブル自体にプライマリキーがない場合、重複行を MERGE テーブルに挿入すると、サーバがクラッシュした( Bug#41305 )。

・ HANDLER をサポートしない別のストレージエンジンを使用するようにテーブルが変更されたために、 HANDLER で開いたテーブルを再度開く必要がある場合、サーバはハングの問題を確実に処理していなかった。また、再オープンの試行に失敗した場合、サーバはエラーの設定にも失敗した。これらの問題により、サーバがクラッシュまたはハングする可能性があった( Bug#41110 、 Bug#41112 )。

・ MyISAM テーブルに対する INSERT ステートメントと同時に SELECT ステートメントを実行すると、不正な結果がクエリキャッシュから返される可能性があった( Bug#41098 )。

・プリペアドステートメントでは、文字列値の max_length を計算する際にマルチバイト文字セットが考慮されていなかった。また、 mysql_stmt_fetch() は、切り捨てられた文字列を返す可能性があった( Bug#41078 )。

・MySQL5.2に適用された非推奨警告は、MySQL6.0に適用するように変更された( Bug#41077 )。

・クエリ結果におけるユーザ定義変数の場合、不正な長さ値が結果メタデータで返された( Bug#41030 )。

・Windowsでは、 innodb_flush_method に無効な値を使用してサーバを起動すると、サーバがクラッシュした( Bug#40757 )。

・インデックスマージアルゴリズムとMERGEテーブルを使用すると、MySQL5.1がクラッシュした。

インデックスマージアルゴリズムを使用している場合、MyISAMMERGEテーブルでのクエリによるクラッシュが発生した( Bug#40675 )。

・厳格SQLモードを有効にした場合、システム変数を範囲外の値に設定すると、表明違反が発生した( Bug#40657 )。

・キャッシングではなくmmapを使用したため、テーブルテンポラリスキャンは、 myisam_use_mmap システム変数を無効にしても必要以上に遅くなった( Bug#40634 )。

・別のデータベースにあるテーブルを参照するビューの場合、 mysqldump は現在のデータベース名で修飾されたビュー名を書き込んだ。これにより、ダンプファイルを別のデータベースにリロードすることはできなくなる( Bug#40345 )。

・long変数とpointer変数のサイズが異なるプラットフォームでは、 MyISAM がキー統計を不正にコピーし、その結果、サーバのクラッシュや間違ったカーディナリティ値が発生する可能性があった( Bug#40321 )。

・ DELETE は、 WHERE 句のサブクエリ内でアクセスされるテーブルの書き込み(読み取りではない)ロックを取得しようとした( Bug#39843 )。

・ perror は、エラーコード153~163に対する正しい出力を生成しなかった( Bug#39370 )。

・ libmysqld の一部の関数は、エラーが発生すると、エラーを呼び出し元に返すのではなく exit() を呼び出した( Bug#39289 )。

・ innodb_log_arch_dir システム変数は使用できなくなっているが、MySQLディストリビューションに付属する一部のサンプルオプションファイル( my-huge.cnf など)には存在していた。その行はコメントとして存在していたが、非コメント化するとサーバの起動が失敗するため、その行は削除されている( Bug#38249 )。

・既存のセーブポイントと同じ名前を使用してセーブポイントを設定すると、その間に設定されていた他のセーブポイントが誤って削除された。たとえば、 a 、 b 、 c 、 b という名前のセーブポイントを設定すると、 a 、 c 、 b という正しいセーブポイントではなく a 、 b というセーブポイントになった( Bug#38187 )。

・ myisamchk の --help 出力には --HELP オプションがリストされなかった( Bug#38103 )。

・ (a,b)=(c,d) などの行コンストラクタの比較を実行すると、文字列カラムに対する不要な Illegalmixofcollations エラーが発生した( Bug#37601 )。

・テーブルを参照するビューを作成したユーザがそのテーブルに対する結合解除の権限を持っている場合、表明違反が発生した( Bug#37191 )。

・ MATCH() 関数の引数がカラム名以外の式に対するエイリアスだった場合、サーバがクラッシュした( Bug#36737 )。

・ mysql データベースの event 、 general_log 、および slow_log テーブルは server_id 値を格納するが、 UNSIGNED カラムを使用しなかったため、全範囲のID値を格納することはできなかった( Bug#36540 )。

・Windowsでは、 my_global.h の _PC マクロによって現行のコンパイラに問題が発生していた。このマクロは使われなくなったため、削除されている( Bug#34309 )。

・データベース名で修飾された名前を使用する DROPFUNCTION の場合、 lower_case_table_names が1に設定されていても、データベース名の処理では大文字と小文字が区別された( Bug#33813 )。

・ mysqldump--compatible=mysql40 は、 character_set_client システム変数を参照するステートメントを発行した。このシステム変数は、MySQL4.1より古いバージョンでは認識されない。現在、これらのステートメントはバージョン別のコメントで囲まれるようになっている( Bug#33550 )。

・ setsockopt() 、 bind() 、 sched_yield() 、 gtty() など のいくつかの関数は、 configure による検出が失敗する可能性があった( Bug#31506 )。

・ InnoDB テーブルのカラムで MBRTouches() などのMBR空間関数を使用すると、エラーではなくサーバのクラッシュが発生した( Bug#31435 )。

・行の先頭が delimiter コマンドでない場合、 mysql クライアントは入力解析を正しく処理しなかった( Bug#31060 )。

・ SHOWPRIVILEGES は、 Functions,Procedures のコンテキストを持つものとして CREATEROUTINE 権限をリストしたが、この権限はデータベースレベルの権限である( Bug#30305 )。

・ mysqld--help は、rootとして機能しなかった( Bug#30261 )。

・ CHECKTABLE 、 REPAIRTABLE 、 ANALYZETABLE 、および OPTIMIZETABLE は、テーブルが存在しない場合や KILL を使用してステートメントを終了した場合にテーブルの破損を誤ってレポートした( Bug#29458 )。

・ SHOWTABLESTATUS は、非ASCII文字が名前に含まれているテーブルに対して出力の生成に失敗する可能性があった( Bug#25830 )。

・HP-UXでは、エラーメッセージのスタック領域割り当てが小さすぎることがあった。その結果、スタックオーバーフローによるクラッシュが発生した( Bug#21476 )。

・浮動小数点数は、テキストまたはプリペアドステートメントプロトコルが使用されているかどうかに応じて、異なる桁数で処理される可能性があった( Bug#21205 )。

・ ROUND() は、プラットフォームごとに異なる結果を返すことがあった( Bug#15936 )。

  • 免責条項
  • |  サイト利用規定
  • |  個人情報保護方針
  • |  個人情報の取り扱いについて
  • |  情報セキュリティ対策についての宣言文
  • |  
  • |  アクセスマップ
© Copyright Nomura Research Institute, Ltd. All rights reserved. オープンソースはOpenStandia