無料スクリプト配布のPHP.TO   PHPの実用的なtips PHPマニュアル MySQLマニュアル Apacheマニュアル PostgreSQLマニュアル マニュアル検索    

18.17. 開発者向けのオプション

以下のパラメータは、 PostgreSQL のソースコードに対する作業用のものです。 中には深刻な損傷を負ったデータベースの復旧に役立つものもあります。 実運用のデータベースでこれらを設定する理由はないはずです。 したがって、これらはサンプルの postgresql.conf からは除外されています。 これらのパラメータの多くは、それを動作させるために特殊なソースコンパイルを必要としていることに注意してください。

allow_system_table_mods ( boolean )

システムテーブルの構造変更を許可します。 これは initdb で使用されます。 このパラメータはサーバ起動時にのみ設定可能です。

debug_assertions ( boolean )

各種のアサーション検査を有効にします。 これはデバッグ用の道具です。 もしおかしな問題とかクラッシュを経験すれば、プログラミングの間違いが顕在化するので、これを有効にする必要があるかもしれません。 このパラメータを使用するには、マクロ USE_ASSERT_CHECKING が、 PostgreSQL の構築時に( configure オプションの --enable-cassert で)定義されなければなりません。もし、 PostgreSQL がアサーション付で構築されていれば、 debug_assertions のデフォルトは on であることに注意してください。

ignore_system_indexes ( boolean )

システムテーブルの読み込み時にシステムインデックスを無視します(しかしテーブルが更新された時はインデックスを更新します)。 障害があるシステムインデックスを復旧する時、これは有用です。 セッションが始まった後に、このパラメータを変更することはできません。

post_auth_delay ( integer )

非ゼロの場合、サーバプロセスが始まり認証手続きが終わった後に、指定した秒数の遅延が発生します。 これは、デバッガを使用してサーバプロセスに接続する機会を開発者に提供することを目的としています。 セッションが始まった後に、このパラメータを変更することはできません。

pre_auth_delay ( integer )

非ゼロの場合、ここで指定した秒数分の遅延が新しくサーバプロセスがforkした後、認証手続きに入る前に発生します。 これは、認証における誤動作を追跡するために、デバッガを使用してサーバプロセスに接続する機会を開発者に提供することを目的としたものです。 このパラメータは postgresql.conf ファイル内、または、サーバのコマンドラインでのみ設定可能です。

trace_notify ( boolean )

LISTEN NOTIFY コマンドのための大量なデバッグ出力を生成します。 この出力をクライアントもしくはサーバログに送信するためには、それぞれ、 client_min_messages もしくは log_min_messages DEBUG1 以下でなければなりません。

trace_recovery_messages ( enum )

復旧関連のデバッグ出力のログ取得を有効にします。さもないとログは取られません。 このパラメータはユーザに対し、 log_min_messages の通常設定を上書きすることを許可します。 しかし、特定のメッセージに対してのみです。これはホットスタンバイのデバッグを意図したものです。 有効な値は、 DEBUG5 DEBUG4 DEBUG3 DEBUG2 DEBUG1 、および LOG です。 デフォルトの LOG は、ログ取得の決定に全く影響しません。 その他の値は、あたかも LOG 優先度を所有しているごとく、それ、またはより高い優先度でログ取得される復旧関連デバッグメッセージの要因となります。 log_min_messages の通常設定に対し、これは無条件にそれらをサーバログに送り込みます。 このパラメータは postgresql.conf ファイル内、または、サーバコマンドラインでのみ設定可能です。

trace_sort ( boolean )

もしも有効であれば、並び替え操作の間のリソース使用についての情報を放出します。 このパラメータは PostgreSQL がコンパイルされた時、 TRACE_SORT マクロが定義されている場合にのみ有効です。 (とは言っても、現在 TRACE_SORT はデフォルトで定義されています。)

trace_locks ( boolean )

有効な場合、ロックの使用状況に関する情報を出力します。 出力される情報には、ロック操作の種類、ロックの種類、ロックまたはロック解除されているオブジェクトの一意な識別子が含まれます。 また、このオブジェクトに既に与えられているロック種類やこのオブジェクトで待機しているロック種類を表すビットマスクも含まれます。 ロック種類それぞれについて、与えられているロック数、待機中のロック数がその総数と共に出力されます。 ログファイル出力例を以下に示します。

LOG:  LockAcquire: new: lock(0xb7acd844) id(24688,24696,0,0,0,1)
      grantMask(0) req(0,0,0,0,0,0,0)=0 grant(0,0,0,0,0,0,0)=0
      wait(0) type(AccessShareLock)
LOG:  GrantLock: lock(0xb7acd844) id(24688,24696,0,0,0,1)
      grantMask(2) req(1,0,0,0,0,0,0)=1 grant(1,0,0,0,0,0,0)=1
      wait(0) type(AccessShareLock)
LOG:  UnGrantLock: updated: lock(0xb7acd844) id(24688,24696,0,0,0,1)
      grantMask(0) req(0,0,0,0,0,0,0)=0 grant(0,0,0,0,0,0,0)=0
      wait(0) type(AccessShareLock)
LOG:  CleanUpLock: deleting: lock(0xb7acd844) id(24688,24696,0,0,0,1)
      grantMask(0) req(0,0,0,0,0,0,0)=0 grant(0,0,0,0,0,0,0)=0
      wait(0) type(INVALID)

ダンプされる構造の詳細は、 src/include/storage/lock.h にあります。

このパラメータは PostgreSQL がコンパイル時に LOCK_DEBUG マクロが定義された場合のみ有効です。

trace_lwlocks ( boolean )

有効な場合、軽量ロックの使用状況に関する情報を出力します。 軽量ロックは主に、共有メモリ上のデータ構造へのアクセスに関する排他制御機能を提供することを意図したものです。

このパラメータは PostgreSQL がコンパイル時に LOCK_DEBUG マクロが定義された場合のみ有効です。

trace_userlocks ( boolean )

有効な場合、ユーザロックの使用状況に関する情報を出力します。 出力は trace_locks と同じですが、助言ロックに関するもののみを出力します。

このパラメータは PostgreSQL がコンパイル時に LOCK_DEBUG マクロが定義された場合のみ有効です。

trace_lock_oidmin ( integer )

設定すると、このOID未満のテーブルに関するロックの追跡を行いません。 (システムテーブルに関する出力を抑えるために使用します。)

このパラメータは PostgreSQL がコンパイル時に LOCK_DEBUG マクロが定義された場合のみ有効です。

trace_lock_table ( integer )

このテーブル(OID)に対し無条件でロックを追跡します。

このパラメータは PostgreSQL がコンパイル時に LOCK_DEBUG マクロが定義された場合のみ有効です。

debug_deadlocks ( boolean )

設定すると、デッドロックタイムアウトが発生した時全ての進行中のロックについての情報がダンプされます。

このパラメータは PostgreSQL がコンパイル時に LOCK_DEBUG マクロが定義された場合のみ有効です。

log_btree_build_stats ( boolean )

設定すると、各種B-Tree操作に関するシステムリソース(メモリとCPU)の使用についての統計情報をログに出力します。

このパラメータは PostgreSQL がコンパイル時に BTREE_BUILD_STATS マクロが定義された場合のみ有効です。

wal_debug ( boolean )

もしonであれば、WALに関連したデバッグ出力が有効になります。このパラメータは WAL_DEBUG マクロが PostgreSQL のコンパイルの時に定義された場合にのみ有効です。

ignore_checksum_failure ( boolean )

data checksums が有効の時のみ効果があります。

読み込み過程でチェックサム障害が検出されると、通常 PostgreSQL はエラーを報告し、現時点のトランザクションを停止します。 ignore_checksum_failure を有効(on)に設定するとシステムはその障害を無視し(しかし警告は報告をします)、処理を継続します。 この振る舞いはたぶん クラッシュの原因、破損の伝播や隠ぺい、もしくはその他の深刻な問題 の原因になることがあります。 とは言っても、エラーを切り抜け、ブロックヘッダが健全に存在するテーブルにある障害を受けていないタプルの回収は行えます。 もしヘッダーが破損されたら、オプションが有効になっていたとしても報告はなされます。 デフォルトの設定は off で、スーパユーザのみが変更可能です。

zero_damaged_pages ( boolean )

ページヘッダの障害がわかると、通常 PostgreSQL はエラーの報告を行い、現在のトランザクションを中断させます。 zero_damaged_pages をonに設定することにより、システムは代わりに警告を報告し、障害のあるメモリ内のページをゼロで埋め、処理を継続します。 この動作により、障害のあったページ上にある全ての行の データが破壊 されます。 しかし、これによりエラーを確実に無視し、正常なページに存在するテーブル内の行を取り出すことができます。 ハードウェアまたはソフトウェアのエラーによって破損が発生した場合のデータの復旧時に有用です。 障害のあるページからのテーブルのデータの復旧をあきらめた場合を除き、通常はこれをonにしてはいけません。 ゼロで埋められたページはディスクに書き込みを強要されないため、このパラメータを再び無効にする以前にテーブル、またはインデックスを再作成することを勧めます。 デフォルトは off であり、スーパーユーザのみ変更可能です。


powered by SEO.CUG.NET