以下のパラメータは、PostgreSQLのソースコードに対する作業用のものです。
中には深刻な損傷を負ったデータベースの復旧に役立つものもあります。
実運用のデータベースでこれらを設定する理由はないはずです。
したがって、これらはサンプルのpostgresql.confからは除外されています。
これらのパラメータの多くは、それを動作させるために特殊なソースコンパイルを必要としていることに注意してください。
allow_system_table_mods (boolean)
システムテーブルの構造変更を許可します。
これはinitdbで使用されます。
このパラメータはサーバ起動時にのみ設定可能です。
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_consistency_checking (string)
このパラメータは、WALのREDOルーチンのバグをチェックするために使うことを意図しています。 有効にすると、WALレコードと一緒に変更されたバッファのフルページイメージをレコードに追加します。 後でそのレコードがリプレイされるときは、システムはまず各々のレコードを適用し、次にレコードによって変更されたバッファが、格納したイメージと一致するかどうかをテストします。 ある種のケース（たとえばヒントビット）では、些細な変化は許容され、無視されます。 予期しない差異は、致命的エラーを引き起こし、リカバリが中断されます。
デフォルト値は空文字で、この機能を無効にします。
すべてのレコードをチェックするために、allにすることができます。
カンマ区切りのリストにすると、対応するリソースマネージャに由来するレコードのみをチェックします。
今のところ、サポートされているリソースマネージャは、heap、heap2、btree、hash、gin、gist、sequence、spgist、brin、genericです。
スーパーユーザだけがこの設定を変更できます。
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であり、スーパーユーザのみ変更可能です。