以下のパラメータは、開発者のテスト用であり、決して実運用のデータベースに使わないでください。
しかし、中には深刻な損傷を負ったデータベースの復旧に役立つものもあります。
したがって、これらはサンプルのpostgresql.conf
からは除外されています。
これらのパラメータの多くは、それを動作させるために特殊なソースコンパイルを必要としていることに注意してください。
allow_in_place_tablespaces
(boolean
)
CREATE TABLESPACE
コマンドに空の位置文字列が渡された時に、pg_tblspc
内にテーブル空間をディレクトリとして作ることを可能にします。
これは、プライマリとスタンバイサーバが同じマシン上で実行されるレプリケーションシナリオをテストするために使用することを意図しています。
このようなディレクトリは、その場所にシンボリックリンクだけが見つかることを期待しているバックアップツールを混乱させる可能性が高いでしょう。
スーパーユーザと、適切なSET
権限を持つユーザのみがこの設定を変更することができます。
allow_system_table_mods
(boolean
)
システムテーブルの構造変更とその他の危険性の高いシステムテーブルに対するアクションを許可します。
これは通常スーパーユーザにさえ許可されません。
この設定の無分別な使用は回復不能なデータ喪失やデータベースシステムの重大な破損を招きます。
スーパーユーザと、適切なSET
権限を持つユーザのみがこの設定を変更することができます。
backtrace_functions
(string
)
このパラメータはカンマ区切りのC関数名を含みます。 エラーが発生し、エラー発生箇所の内部C関数がこのリストの値と一致すると、エラーメッセージとともにバックトレースが一緒にサーバログに書かれます。 これはソースコードの特定箇所をデバッグするのに役立ちます。
バックトレースのサポートはすべてのプラットフォームで提供されているわけではありませんし、バックトレースの品質はコンパイルオプションに依存します。
この設定を変更できるのは、スーパーユーザと適切なSET
権限を持つユーザだけです。
debug_discard_caches
(integer
)
1
なら、可能な最初の機会にシステムカタログのキャッシュ項目が破棄されます。
すべてのキャッシュ項目を無効にするすべてのことが実際に起きます。
結果としてシステムカタログのキャッシュが無効になり、サーバは極めて低速に動作します。
1より大きければ、再帰的にキャッシュを削除します。
これは更に遅くなり、キャッシュのロジック自体をテストするときにだけ役に立ちます。
デフォルト値の0
で正常なカタログキャッシュは通常の動作になります。
このパラメータは並行的なカタログの変更を伴う再現しにくいバグを引き起こす際にとても役に立ちますが、それ以外にはめったに必要になりません。
詳細はinval.c
とpg_config_manual.h
のソースコードファイルを見てください。
このパラメータはコンパイル時にDISCARD_CACHES_ENABLED
が定義されたとき(これはconfigureオプションの--enable-cassert
が使われたときに自動的に起こります)にサポートされます。
実運用のビルドでは0
となり、それ以外の値に設定しようとするとエラーが起こります。
force_parallel_mode
(enum
)
性能改善が期待できなくても、テスト目的のためにパラレルクエリを利用できるようにします。
force_parallel_mode
に設定できる値は、off
(性能改善が期待できるときにだけパラレルクエリを使用する)、on
(安全なクエリに対しては常にパラレルクエリを強制する)、regress
(on
と同様だが、下記のような振る舞いの変更を伴う)です。
正確に言えば、この値をon
にすると、安全と見なされるすべての問い合わせ計画の上にGather
ノードを追加し、クエリをパラレルワーカー上で実行するようにします。
プランナがこれによってクエリが失敗すると思わない限り、パラレルワーカーが利用できない、あるいは使用できないような場合でも、たとえばサブトランザクションの開始のように、パラレルクエリコンテキストでは許可されない操作は不許可となります。
このオプションを設定することによって、エラーとなったり、あるいは期待していなかった結果がもたらされる場合には、クエリで使用されている関数はPARALLEL UNSAFE
(もしくは、PARALLEL RESTRICTED
)と印を付ける必要があるかもしません。
この設定値をregress
とすると、on
とするのに加え、自動リグレッションテストを助けるための付加的な効果が現れます。
通常パラレルワーカーからのメッセージは、そのことを表すコンテキスト行を表示しますが、regress
と設定すると、非パラレル実行と同じ出力になるように、これを抑止します。
また、プランに追加されたGather
ノードは、EXPLAIN
出力から隠され、off
に設定したときと同じ出力が得られるようにします。
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
です。
拡張は追加のリソースマネージャを定義しても構いません。
スーパーユーザと、適切なSET
権限を持つユーザのみがこの設定を変更することができます。
wal_debug
(boolean
)
もしonであれば、WALに関連したデバッグ出力が有効になります。このパラメータはWAL_DEBUG
マクロが PostgreSQLのコンパイルの時に定義された場合にのみ有効です。
ignore_checksum_failure
(boolean
)
data checksumsが有効の時のみ効果があります。
読み込み過程でチェックサム障害が検出されると、通常PostgreSQLはエラーを報告し、現時点のトランザクションを停止します。
ignore_checksum_failure
を有効(on)に設定するとシステムはその障害を無視し(しかし警告は報告をします)、処理を継続します。
この振る舞いはたぶんクラッシュの原因、破損の伝播や隠ぺい、もしくはその他の深刻な問題の原因になることがあります。
とは言っても、エラーを切り抜け、ブロックヘッダが健全に存在するテーブルにある障害を受けていないタプルの回収は行えます。
もしヘッダーが破損されたら、オプションが有効になっていたとしても報告はなされます。
デフォルトの設定はoff
です。
スーパーユーザと、適切なSET
権限を持つユーザのみがこの設定を変更することができます。
zero_damaged_pages
(boolean
)
ページヘッダの障害がわかると、通常PostgreSQLはエラーの報告を行い、現在のトランザクションを中断させます。
zero_damaged_pages
をonに設定することにより、システムは代わりに警告を報告し、障害のあるメモリ内のページをゼロで埋め、処理を継続します。
この動作により、障害のあったページ上にある全ての行のデータが破壊されます。
しかし、これによりエラーを確実に無視し、正常なページに存在するテーブル内の行を取り出すことができます。
ハードウェアまたはソフトウェアのエラーによって破損が発生した場合のデータの復旧時に有用です。
障害のあるページからのテーブルのデータの復旧をあきらめた場合を除き、通常はこれをonにしてはいけません。
ゼロで埋められたページはディスクに書き込みを強要されないため、このパラメータを再び無効にする以前にテーブル、またはインデックスを再作成することを勧めます。
デフォルトはoff
です。
スーパーユーザと、適切なSET
権限を持つユーザのみがこの設定を変更することができます。
ignore_invalid_pages
(boolean
)
off
(デフォルトです)に設定すると、無効なページを参照しているWALレコードはPostgreSQLに対してPANICレベルのエラーを引き起こし、リカバリをアボートします。
ignore_invalid_pages
をon
に設定すると、WALレコードの無効なページへの参照を無視し(しかしワーニングは報告されます)、リカバリを継続します。
この振る舞いにより、クラッシュ、データロス、破壊を増長したり見えなくするなどの深刻な問題を被るかもしれません。
しかし、これによってPANICレベルのエラーを回避してリカバリを完了し、サーバを起動できるかもしれません。
このパラメータはサーバ起動時にのみ設定できます。
リカバリ中、あるいはスタンバイモードでのみ効果があります。
jit_debugging_support
(boolean
)
LLVMに要求された機能がある場合は、生成した関数をGDB用に登録します。
これにより、デバッグが容易になります。
デフォルト設定はoff
です。
このパラメータはサーバ起動時のみ設定可能です。
jit_dump_bitcode
(boolean
)
生成されたLLVM IRをdata_directory内のファイルシステムに出力します。
これはJITコンパイルのインターナルについて作業するときだけ有用です。
デフォルト設定はoff
です。
スーパーユーザと、適切なSET
権限を持つユーザのみがこの設定を変更することができます。
jit_expressions
(boolean
)
JITコンパイルが有効な時に式がJITコンパイルされるかどうかを決定します。
(32.2参照。)
デフォルトはon
です。
jit_profiling_support
(boolean
)
LLVMに要求された機能がある場合は、JITが生成した関数をperfでプロファイルすることができるデータを出力します。
これにより~/.debug/jit/
にファイルが書き出されます。
ユーザは自分の責任で必要なときに後始末を行わなければなりません。
デフォルト設定はoff
です。
jit_tuple_deforming
(boolean
)
JITコンパイルが有効な時にタプルデフォーミングがJITコンパイルされるかどうかを決定します。
(32.2参照。)
デフォルトはon
です。
remove_temp_files_after_crash
(boolean
)
デフォルトであるon
に設定すると、PostgreSQLはバックエンドがクラッシュした後に自動的に一時ファイルを削除します。
無効にすると、ファイルは保存され、たとえばデバッグ目的で使用できます。
しかしクラッシュを繰り返すと不要なファイルが溜まっていくかもしれません。
このパラメータはpostgresql.conf
ファイル内、またはサーバのコマンドラインのみで設定可能です。