CREATE TABLESPACEコマンドに空の位置文字列が渡された時に、pg_tblspc内にテーブル空間をディレクトリとして作ることを可能にします。 これは、プライマリとスタンバイサーバが同じマシン上で実行されるレプリケーションシナリオをテストするために使用することを意図しています。 このようなディレクトリは、その場所にシンボリックリンクだけが見つかることを期待しているバックアップツールを混乱させる可能性が高いでしょう。 スーパーユーザだけがこの設定を変更できます。

システムテーブルの構造変更とその他の危険性の高いシステムテーブルに対するアクションを許可します。 これは通常スーパーユーザにさえ許可されません。 この設定の無分別な使用は回復不能なデータ喪失やデータベースシステムの重大な破損を招きます。 スーパーユーザだけがこの設定を変更できます。

このパラメータはカンマ区切りのC関数名を含みます。 エラーが発生し、エラー発生箇所の内部C関数がこのリストの値と一致すると、エラーメッセージとともにバックトレースが一緒にサーバログに書かれます。 これはソースコードの特定箇所をデバッグするのに役立ちます。

バックトレースのサポートはすべてのプラットフォームで提供されているわけではありませんし、バックトレースの品質はコンパイルオプションに依存します。

スーパーユーザだけがこのパラメータを設定できます。

1なら、可能な最初の機会にシステムカタログのキャッシュ項目が破棄されます。 すべてのキャッシュ項目を無効にするすべてのことが実際に起きます。 結果としてシステムカタログのキャッシュが無効になり、サーバは極めて低速に動作します。 1より大きければ、再帰的にキャッシュを削除します。 これは更に遅くなり、キャッシュのロジック自体をテストするときにだけ役に立ちます。 デフォルト値の0で正常なカタログキャッシュは通常の動作になります。

このパラメータは並行的なカタログの変更を伴う再現しにくいバグを引き起こす際にとても役に立ちますが、それ以外にはめったに必要になりません。 詳細はinval.cとpg_config_manual.hのソースコードファイルを見てください。

このパラメータはコンパイル時にDISCARD_CACHES_ENABLEDが定義されたとき（これはconfigureオプションの--enable-cassertが使われたときに自動的に起こります）にサポートされます。 実運用のビルドでは0となり、それ以外の値に設定しようとするとエラーが起こります。

性能改善が期待できなくても、テスト目的のためにパラレルクエリを利用できるようにします。 force_parallel_modeに設定できる値は、off（性能改善が期待できるときにだけパラレルクエリを使用する）、on（安全なクエリに対しては常にパラレルクエリを強制する）、regress（onと同様だが、下記のような振る舞いの変更を伴う）です。

正確に言えば、この値をonにすると、安全と見なされるすべての問い合わせ計画の上にGatherノードを追加し、クエリをパラレルワーカー上で実行するようにします。 プランナがこれによってクエリが失敗すると思わない限り、パラレルワーカーが利用できない、あるいは使用できないような場合でも、たとえばサブトランザクションの開始のように、パラレルクエリコンテキストでは許可されない操作は不許可となります。 このオプションを設定することによって、エラーとなったり、あるいは期待していなかった結果がもたらされる場合には、クエリで使用されている関数はPARALLEL UNSAFE（もしくは、PARALLEL RESTRICTED）と印を付ける必要があるかもしません。

この設定値をregressとすると、onとするのに加え、自動リグレッションテストを助けるための付加的な効果が現れます。 通常パラレルワーカーからのメッセージは、そのことを表すコンテキスト行を表示しますが、regressと設定すると、非パラレル実行と同じ出力になるように、これを抑止します。 また、プランに追加されたGatherノードは、EXPLAIN出力から隠され、offに設定したときと同じ出力が得られるようにします。

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

サーバプロセスが始まり認証手続きが終わった後の遅延時間です。 これは、デバッガを使用してサーバプロセスに接続する機会を開発者に提供することを目的としています。 この値が単位なしで指定された場合は、秒単位であるとみなします。 値がゼロ（デフォルト）の場合、この遅延は無効になります。 セッションが始まった後に、このパラメータを変更することはできません。

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

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

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

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

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

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マクロが定義された場合のみ有効です。

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

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

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

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

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

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

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

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

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

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

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

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

このパラメータは、WALのREDOルーチンのバグをチェックするために使うことを意図しています。 有効にすると、WALレコードと一緒に変更されたバッファのフルページイメージをレコードに追加します。 後でそのレコードがリプレイされるときは、システムはまず各々のレコードを適用し、次にレコードによって変更されたバッファが、格納したイメージと一致するかどうかをテストします。 ある種のケース（たとえばヒントビット）では、些細な変化は許容され、無視されます。 予期しない差異は、致命的エラーを引き起こし、リカバリが中断されます。

デフォルト値は空文字で、この機能を無効にします。 すべてのレコードをチェックするために、allにすることができます。 カンマ区切りのリストにすると、対応するリソースマネージャに由来するレコードのみをチェックします。 今のところ、サポートされているリソースマネージャは、heap、heap2、btree、hash、gin、gist、sequence、spgist、brin、genericです。 スーパーユーザだけがこの設定を変更できます。

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

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

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

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

off（デフォルトです）に設定すると、無効なページを参照しているWALレコードはPostgreSQLに対してPANICレベルのエラーを引き起こし、リカバリをアボートします。 ignore_invalid_pagesをonに設定すると、WALレコードの無効なページへの参照を無視し（しかしワーニングは報告されます）、リカバリを継続します。 この振る舞いにより、クラッシュ、データロス、破壊を増長したり見えなくするなどの深刻な問題を被るかもしれません。 しかし、これによってPANICレベルのエラーを回避してリカバリを完了し、サーバを起動できるかもしれません。 このパラメータはサーバ起動時にのみ設定できます。 リカバリ中、あるいはスタンバイモードでのみ効果があります。

LLVMに要求された機能がある場合は、生成した関数をGDB用に登録します。 これにより、デバッグが容易になります。 デフォルト設定はoffです。 このパラメータはサーバ起動時のみ設定可能です。

生成されたLLVM IRをdata_directory内のファイルシステムに出力します。 これはJITコンパイルのインターナルについて作業するときだけ有用です。 デフォルト設定はoffです。 このパラメータはスーパーユーザだけが変更可能です。

JITコンパイルが有効な時に式がJITコンパイルされるかどうかを決定します。 （32.2参照。） デフォルトはonです。

LLVMに要求された機能がある場合は、JITが生成した関数をperfでプロファイルすることができるデータを出力します。 これにより~/.debug/jit/にファイルが書き出されます。 ユーザは自分の責任で必要なときに後始末を行わなければなりません。 デフォルト設定はoffです。

JITコンパイルが有効な時にタプルデフォーミングがJITコンパイルされるかどうかを決定します。 （32.2参照。） デフォルトはonです。

デフォルトであるonに設定すると、PostgreSQLはバックエンドがクラッシュした後に自動的に一時ファイルを削除します。 無効にすると、ファイルは保存され、たとえばデバッグ目的で使用できます。 しかしクラッシュを繰り返すと不要なファイルが溜まっていくかもしれません。 このパラメータはpostgresql.confファイル内、またはサーバのコマンドラインのみで設定可能です。