複数のスタンバイサーバ、またはストリーミングを基盤とする予備（バックアップ）クライアントからの同時接続を受ける接続最大値を設定します（つまり、同時に稼動するWAL送信プロセスの最大値です）。 デフォルトはゼロです。その意味するところはレプリケーションは無効です。 WAL送出プロセスは接続の総数カウントに考慮されるため、max_connectionsを越えたパラメータの設定できません。 クライアント接続が突然切断されると、タイムアウトするまで孤児接続スロットが残ってしまうかもしれません。 ですから、このパラメータは想定されるクライアント数の最大値よりも少し大きめにして、切断されたクライアントが直ちに再接続できるようにした方が良いでしょう。 このパラメータはサーバ起動時のみ設定可能です。 スタンバイサーバからの接続を許可するには、wal_levelがarchive以上に設定しておかなければなりません。

サーバが使用できるレプリケーションスロット(25.2.6. レプリケーションスロット参照)の最大数を指定します。デフォルトは0です。 このパラメータはサーバ起動時のみ設定可能です。 レプリケーションスロットが使用できるためには、wal_levelを archive以上に設定しなければなりません。 現在存在しているレプリケーションスロットの数よりも少ない値を設定すると、サーバは起動しません。

ストリーミングレプリケーションにおいて、スタンバイサーバが過去のファイルセグメントを取得する必要がある場合に備え、pg_xlogディレクトリに保持しておくファイルセグメント数の最小値を指定します。 それぞれのセグメントは通常16メガバイトです。 もし送出サーバに接続しているスタンバイサーバがwal_keep_segmentsセグメントを越えて遅延した場合、送出サーバはスタンバイサーバが今後とも必要とするWALセグメントを削除する可能性があります。 この場合、レプリケーション接続は終了させられます。結果として下流に対する接続も結局は終了されることがあります。（しかし、WALアーカイブが使用されていれば、スタンバイサーバはアーカイブからセグメントを取り出し、復旧することができます。）

pg_xlogに保持され続けるセグメントの最小値のみを設定します。 システムはWALアーカイブのため、またはチェックポイントからの復旧のため、より多くのセグメント保持が必要となることがあります。もしwal_keep_segmentsが（デフォルトの）ゼロの場合、システムはスタンバイサーバのために追加セグメントを保持することはしません。 従って、スタンバイサーバが使用できる古いWALセグメントの数は、直前のチェックポイントの場所とWALアーカイブの状況によって算出されます。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。

指定されたミリ秒単位の値より長く非活動のレプリケーション接続を停止します。 スタンバイサーバのクラッシュ、またはネットワークの停止を送出サーバが検出することにこれが役立ちます。 値ゼロはタイムアウト機能を無効にします。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。 デフォルトの値は60秒です。

トランザクションのコミットタイムを記録します。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。 デフォルトはoffです。

25.2.8. 同期レプリケーションで説明されているように、同期レプリケーションをサポート可能なスタンバイサーバの名前をコンマで区切られたリストで指定します。 いつの時点においても、活動している同期スタンバイサーバは最大でも1つです。 コミットを待機しているトランザクションは、このスタンバイサーバがそのデータの受信を確認してから処理の継続が許可されます。 同期スタンバイサーバはこのリストで一番目に名前が挙げられていており、現時点で接続され、そしてデータをリアルタイムでストリーミングしているものです（pg_stat_replication ビューにおいてストリーミング状態として示されています）。 このリストの後の方に記載されているその他のスタンバイサーバは潜在的に同期スタンバイサーバになることを示しています。 もし現在の同期スタンバイサーバが理由にかかわらず切断された場合、次に順位の高いスタンバイサーバがすぐに取って代わります。 二つ以上のスタンバイサーバ名を指定することでかなりの高可用性が得られます。

この目的のスタンバイサーバの名前は、スタンバイサーバのWAL receiverのprimary_conninfoで設定されるのと同じく、スタンバイサーバのapplication_name設定となります。 一意性を強要する仕組みにはなっていません。 walreceiverのデフォルトのアプリケーション名を含めて、特別の記載である*は全てのapplication_nameにマッチします。

ここに同期スタンバイ名が指定されていない場合、同期レプリケーションは有効とはならず、トランザクションコミットはレプリケーションを待機しません。これがデフォルトの設定です。同期レプリケーションが有効であっても、synchronous_commitパラメータをlocal または offに設定することにより、個別のトランザクションをレプリケーションに対して待機しないように設定できます。

このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。

VACUUM および HOT更新が不要行バージョンの回収を決めるのを延期するトランザクションの数を指定します。デフォルトはゼロトランザクションです。この意味は、不要行バージョンは速やかに削除され、いかなる開いているトランザクションから直ちに不可視となります。 25.5. ホットスタンバイに記載されているように、ホットスタンバイサーバをサポートしている場合、非ゼロ値に設定したい場合があります。そうすることで、スタンバイ上での問い合わせが、行の早期回収によるコンフリクトを被ることなく完了するように時間を与える。しかし、値はプライマリーサーバ上で発生している書き込みトランザクションの観点から計測されるため、スタンバイの問い合わせにたいして猶予時間がどのくらい有効となるかは予測できません。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。

このパラメータの使用の代わりにスタンバイサーバ上に hot_standby_feedbackの設定を考慮する必要もあります。

25.5. ホットスタンバイに記載されている通り、リカバリの最中に接続し、そして問い合わせを実行できるか否かを設定します。デフォルト値はoffです。 このパラメータはサーバ起動時のみ設定可能です。これは、アーカイブリカバリ期間、又はスタンバイモードにある場合にのみ効果をもたらします。

ホットスタンバイが稼動している場合、このパラメータは25.5.2. 問い合わせコンフリクトの処理で記載されているように、まさに適用されようとしているWALエントリと衝突するスタンバイサーバの問い合わせをキャンセルするにはどれだけ待機しなければならないかを設定します。 max_standby_archive_delayはWALデータをWALアーカイブから読み込んでいる時に適用されます（従って最新ではありません）。 デフォルトは30秒です。特に指定が無ければ単位はミリ秒です。値-1は衝突する問い合わせが完了するまでスタンバイサーバが待ち続けられるようにします。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。

max_standby_archive_delayはキャンセル前に問い合わせが実行できる最大の時間の長さと同じでないことに注意してください。むしろ、任意の１つのWALセグメントのデータに適用される最大許可時間です。従って、ある問い合わせがWALセグメント内で時間的に初期の段階で大幅な遅延となった場合、その後の衝突する問い合わせの猶予時間はましてさらに短くなります。

ホットスタンバイが稼動している場合、このパラメータは25.5.2. 問い合わせコンフリクトの処理で記載されているように、まさに適用されようとしているWALエントリと衝突するスタンバイサーバの問い合わせをキャンセルするにはどれだけ待機しなければならないかを設定します。 max_standby_streaming_delayはWALデータをストリーミングレプリケーションから受け取っている時に適用されます。 デフォルトは30秒です。特に指定が無ければ単位はミリ秒です。値-1は衝突する問い合わせが完了するまでスタンバイサーバが待ち続けられるようにします。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。

max_standby_streaming_delayはキャンセル前に問い合わせが実行できる最大の時間の長さと同じでないことに注意してください。むしろ、プライマリサーバから一度受け取られたWALデータを適用するための最大許可時間です。 従って、ある問い合わせがWALセグメントにおいてそれまでに大幅な遅延となった場合、それに続いて衝突する問い合わせは、スタンバイサーバがふたたび遅れを取り戻すまで、猶予時間はさらに短くなります。

スタンバイサーバ上のWAL受信プロセスがプライマリー、または上位サーバに対してレプリケーションの進捗情報を送信する最小頻度を指定します。送信された進捗情報は pg_stat_replicationビューにより確認することが可能です。 スタンバイサーバは書き込みがされた直近のログ位置、ディスクにフラッシュされた直近のログ位置、およびリカバリ適用された直近のログ位置を報告します。 このパラメータの値がそれぞれの報告間における秒単位の最大の時間間隔です。 書き込み、またはフラッシュ位置が変更される毎、あるいは最低でもこのパラメータで設定された頻度で更新情報が送信されます。 このパラメータをゼロに設定すると、ステータスの更新を完全に無効化します。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。 デフォルトの値は10秒です。

ホットスタンバイがスタンバイサーバ上で現在処理を行っている問い合わせについて、プライマリーまたは上位サーバにフィードバックを送るか否かを指定します。 このパラメータはレコードの回収に起因する問い合わせの取り消しを排除するために使用することができます。 しかし、いくつかのワークロードに対してはプライマリーサーバ上でのデータベース肥大の原因となります。 フィードバックメッセージはwal_receiver_status_interval毎に、2回以上送信されません。 デフォルトの値はoffです。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。

カスケードレプリケーションが使用されている場合、フィードバックは最終的にプライマリーに到達するまで上位サーバに転送されます。スタンバイは上位に転送する以外、受け取ったフィードバックを他に使用しません。

指定されたミリ秒より長い活動していないレプリケーション接続は停止します。 このことは受信するスタンバイサーバがプライマリノードの機能停止、またはネットワーク停止を検出するのに便利です。 値ゼロは時間切れメカニズムを無効にします。このパラメータはpostgresql.confまたはサーバのコマンドラインのみで設定可能です。 デフォルト値は60秒です。

WALデータがソース(ストリーミングレプリケーション、ローカルのpg_xlog、またはWALアーカイブ)から取得できない時に、スタンバイサーバがWALデータ受信をリトライするまでにどの位の時間待つべきかを指定します。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。 デフォルト値は5秒です。 特に指定がなければ単位はミリ秒です。

このパラメータは、リカバリ対象のノードにおいて、新しいWALデータが読み込み可能になるまでの待ち時間を制御する必要のある時に有用です。 たとえば、アーカイブリカバリにおいては、このパラメータの値を小さくすることにより、新しいWALログファイルを検出する際にリカバリの応答を早くすることができます。 WALの生成頻度が少ないシステムでは、この値を大きくすることにより、WALアーカイブへのアクセス頻度を減らすことができます。 これは、たとえば基盤へのアクセス回数が課金対象になるクラウド環境において、有用です。