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

スタンバイサーバを実行する際は、このパラメータをマスタサーバと同じか高い値にしなければなりません。 さもなければ、スタンバイサーバでクエリを実行できなくなります。

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

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

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

チェックポイント時にレプリケーションスロットがpg_walディレクトリに残すことのできる 最大のWALファイルのサイズを指定します。 max_slot_wal_keep_sizeが-1 (デフォルトです)なら、レプリケーションスロットは無制限のWALファイルを残すかも知れません。 そうでなければ、レプリケーションスロットのrestart_lsnが現在のLSNよりも与えられたサイズ分遅れると、そのスロットを使っているスタンバイは必要なWALファイルが削除されたためにレプリケーションを継続できなくなります。 レプリケーションスロットのWALが存在するかどうかはpg_replication_slotsを見て確認できます。

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

地理的に複数の場所に分散したクラスタでは、場所によって異なる値を使うことでクラスタ管理がより柔軟にできるようになります。 より小さな値は低遅延ネットワーク接続上のスタンバイの障害検知をより高速にするのに役立ちます。 遅延の大きなネットワーク接続に設置されたスタンバイの健全性の判断にはより大きな値が助けになるでしょう。

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

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

この目的のためのスタンバイサーバ名は、スタンバイの接続情報で指定された、スタンバイのapplication_name設定です。 物理レプリケーションスタンバイでは、primary_conninfo設定です。 デフォルトはcluster_nameの設定で、さもなければ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で指定された年齢に達した無効行のクリーンアップを妨げることはありません。

スタンバイサーバが送信サーバに接続するための接続文字列を指定します。 この文字列は、33.1.1で説明されている書式で記述されます。 この文字列に何のオプションも指定されていない場合、これに対応する環境変数 (33.14 参照) が確認されます。 環境変数も設定されていなければデフォルトの値が使われます。

接続文字列では、プライマリサーバのホスト名（またはアドレス）、スタンバイサーバのデフォルトと異なるのであればポート番号も指定する必要があります。 また、送信サーバ上で適切な権限を保有するロールのユーザを指定しなければなりません (26.2.5.1 参照)。 送信サーバが要求するのであれば、パスワードも記述される必要があります。 パスワードは primary_conninfoに記述することもできますし、スタンバイサーバ上の分離されたファイル~/.pgpassに記述することもできます (データベース名には replication を使います)。 primary_conninfo文字列の中には、データベース名を指定しないでください。

このパラメータはpostgresql.confか、サーバのコマンドラインでのみ設定可能です。 WAL受信プロセスが実行中にこのパラメータが変更されると、そのプロセスにシグナルが送られ、新しい設定で再起動するために停止します（primary_conninfoが空文字の場合を除きます。） サーバがスタンバイモードでなければこの設定は無効となります。

上流ノードのリソース削除を制御するためにストリーミングレプリケーション経由でプライマリに接続した場合、既存のレプリケーションスロットを使うように、必要に応じて指定します（26.2.6を参照）。 このパラメータはpostgresql.confか、サーバのコマンドラインでのみ設定可能です。 WAL受信プロセスが実行中にこのパラメータが変更されると、そのプロセスにシグナルが送られ、新しい設定で再起動するために停止します。 primary_conninfoが設定されていない場合、この設定は無効です。

スタンバイサーバにおいて、リカバリの完了を示すトリガファイルを指定します。 この値が設定されていなくても、pg_ctl promoteあるいはpg_promote()を使ってスタンバイサーバを昇格させることができます。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。

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データを適用するために許される最大合計時間です。 従って、ある問い合わせが大幅な遅延を起こした場合、その後の衝突する問い合わせは、スタンバイサーバがふたたび遅れを取り戻すまでの間、猶予時間はずっと短くなります。

永続レプリケーションスロットが(primary_slot_nameを使って)作成されない設定になっている時に、WAL受信プロセスがリモートインスタンス上に一時レプリケーションスロットを作るかどうかを指定します。 このパラメータはpostgresql.confか、サーバのコマンドラインでのみ設定可能です。 WAL受信プロセスが実行中にこのパラメータが変更されると、そのプロセスにシグナルが送られ、新しい設定で再起動するために停止します。

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

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

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

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

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

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

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

デフォルトでは、スタンバイサーバは可能な限り早くプライマリからWALレコードをリストアします。 時間遅れのデータのコピーを持つことで、データ損失エラーを修正する機会を提供するのは有用かもしれません。 このパラメータを使う事で、決まった時間だけリカバリを遅らせることができます。 例えば、パラメータに5minと指定した場合、各トランザクションについて、スタンバイのシステム時刻が、マスターから報告されたコミット時刻より5分以上経過している場合のみ、スタンバイサーバはコミットを再生します。 単位を指定しない場合、ミリ秒として扱われます。 デフォルトは0で、遅延を与えません。

サーバ間のレプリケーション遅延はパラメータの値を上回る可能性があり、その場合には遅延は追加されません。 遅延は、マスタサーバで書かれたWALのタイムスタンプと、スタンバイサーバの現在時刻を使って計算されていることに注意してください。 ネットワークの遅延やカスケーディングレプリケーション構成によるデータ転送の遅延は、実際の待ち時間を大幅に減らすかもしれません。 もし、マスタサーバとスタンバイサーバのシステムクロックが同期されていない場合、期待値よりも早くレコードのリカバリを始めるかもしれません。 しかし、このパラメータの有用な設定値は典型的なサーバ間の時間のずれよりもずっと大きいので、それらは大きな問題ではありません。

遅延はトランザクションコミットのWALレコードだけで発生します。 他のレコードは可能な限り早く再生されるでしょう。 対応する（トランザクション）コミットレコードが適用されるまではその効果が不可視であることがMVCCの可視ルールによって保証されているため、他のレコードが可能な限り早く再生されることは問題にはなりません。

ひとたびリカバリ中のデータベースが整合性のとれた状態になれば、スタンバイサーバが昇格またはトリガーになるまで、遅延が発生します。 その後、スタンバイサーバはそれ以上待たずにリカバリを終了します。

このパラメータはストリーミングレプリケーション配信で使われることを目的としていますが、パラメータが指定されていると、クラッシュリカバリを除くすべてのケースで使用されます。 この機能を使うことによってhot_standby_feedbackが遅延され、マスタサーバの肥大化に繋がる可能性があります。両方同時に使う場合には注意して使ってください。

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

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

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

デフォルト値は4です。

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

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

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

デフォルト値は2です。