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

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

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

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

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

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

26.2.8で説明されているように、同期レプリケーションをサポート可能なスタンバイサーバのリストを指定します。 活動中の同期スタンバイサーバは1つまたはそれ以上です。 コミットを待機しているトランザクションは、このスタンバイサーバがそのデータの受信を確認してから処理の継続が許可されます。 同期スタンバイサーバはこのリストに名前が挙げられていており、現時点で接続され、そしてデータをリアルタイムでストリーミングしているものです（pg_stat_replication ビューにおいてstreaming状態として示されています）。 このリストの後の方に記載されているその他のスタンバイサーバは潜在的に同期スタンバイサーバになることを示しています。 二つ以上の同期スタンバイサーバ名を指定することで、かなりの高可用性とデータ損失に対する保護が得られます。

この目的のためのスタンバイサーバ名は、スタンバイの接続情報で指定された、スタンバイのapplication_name設定です。 物理レプリケーションスタンバイでは、recovery.conf中のprimary_conninfo設定です。 デフォルトはwalreceiverです。 論理レプリケーションでは、サブスクリプションの接続情報でで設定でき、デフォルトはサブスクリプション名です。 それ以外のレプリケーションストリームコンシューマーについては、それぞれのドキュメントをご覧ください。

このパラメータは、以下の構文のいずれかを用いてスタンバイサーバのリストを指定します。

[FIRST] num_sync ( standby_name [, ...] )
ANY num_sync ( standby_name [, ...] )
standby_name [, ...]

ここで、num_syncは、トランザクションが応答を待機する必要のある同期スタンバイの数です。 standby_nameは、スタンバイサーバの名前です。 FIRSTとANYは、リスト中のサーバーから同期スタンバイを選ぶ方法を指定します。

キーワードFIRSTをnum_syncと組み合わせると、優先度に基づく同期レプリケーションを指定し、優先度に基づいて選ばれたnum_sync個の同期スタンバイにWALレコードがレプリケーションされるまで、トランザクションのコミットは待機します。 たとえばFIRST 3 (s1, s2, s3, s4)とすると、s1、s2、s3、s4の中から選ばれた優先順位の高い3つのスタンバイサーバが応答を返すまでコミットは待機します。 リストの中で前の方に名前が出現するスタンバイには高い優先度が与えられ、同期と見なされます。 それ以外のリストの中で後の方に名前が上がっているスタンバイサーバーは、潜在的な同期スタンバイであることを表しています。 どんな理由であれ、現在の同期スタンバイが切断されると、次に高い優先度を持つスタンバイに直ちに取って代わられます。 キーワードFIRSTはオプションです。

キーワードANYをnum_syncと組み合わせると、クォーラムに基づく同期レプリケーションを指定し、列挙されたスタンバイのうち少なくともnum_sync個の同期スタンバイにWALレコードがレプリケーションされるまで、トランザクションのコミットを待たせます。 たとえばANY 3 (s1, s2, s3, s4)とすると、s1、s2、s3、s4のうちの少なくとも3つが応答を返した時点でコミットが進行します。

FIRSTとANYは、大文字小文字を区別しません。 もしこれらのキーワードをスタンバイサーバの名前に使う場合は、standby_nameは二重引用符で囲わなければなりません。

3番目の構文は、PostgreSQL9.6よりも前のバージョンで用いられていたもので、依然としてサポートされています。 最初の構文で、FIRST、num_syncを1とした時と同じです。 たとえば、FIRST 1 (s1, s2)とs1, s2は同じ意味です。 s1かs2が同期スタンバイとして選ばれます。

特別なエントリ*は、すべてのスタンバイ名に一致します。

スタンバイの一意性を強要する仕組みはありません。 重複があった場合、一致したスタンバイは優先順位が高いと見なされますが、どれが選ばれるかは非決定的です。

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

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

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

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

old_snapshot_thresholdで指定された年齢に達した無効行のクリーンアップを妨げることはありません。

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

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

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

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

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

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

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

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

この設定は、プライマリのold_snapshot_thresholdの挙動を上書きしません。 プライマリの年齢上限を超えたスタンバイ上のスナップショットは無効となる可能性があり、その場合スタンバイにおいてトランザクションのキャンセルを引き起こします。 これは、old_snapshot_thresholdが、無効行によってデータ溢れが起こる時刻の絶対的な制限を提供することを意図しているからです。 そうでなければ、スタンバイの設定によってこの目的は成立しなくなってしまいます。

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

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

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

論理レプリケーションワーカーの最大数を指定します。 適用ワーカーと、テーブル同期ワーカーの両方が含まれます。

論理レプリケーションワーカーは、max_worker_processesで定義されたプールから取得されます。

デフォルト値は4です。

サブスクリプションごとの同期ワーカーの最大数です。 このパラメータは、サブスクリプションの初期化中、あるいは新しいテーブルが追加されたときの初期データコピーの並列度を制御します。

今のところ、一つのテーブルにつき、同期ワーカーは一つだけです。

同期ワーカーは、max_logical_replication_workersで定義されたプールから取得されます。

デフォルト値は2です。