石井さんのご指摘修正

doc/src/sgml/backup.sgml

@@ -1314,7 +1314,7 @@ WALアーカイブによって<productname>PostgreSQL</productname>データベ
     replay all those WAL segments, and that could take awhile if it has
     been a long time since the last base backup.
 -->
-最後のベースバックアップ以降のWALファイルを保持し続ける必要があるため、通常、ベースバックアップを取得すべき期間は、WALファイルを保持するためにどのくらいのストレージを拡張できるかによって決定されます。
+最後のベースバックアップ以降のアーカイブされたWALファイルを保持し続ける必要があるため、通常、ベースバックアップを取得すべき期間は、アーカイブされたWALファイルを保持するためにどのくらいのストレージを拡張できるかによって決定されます。
 また、復旧が必要になった場合に、どのくらいの時間を復旧に使うと覚悟するのかも考慮すべきです。&mdash;
 システムは全てのWALセグメントを適用する必要があるため、もし、最後のベースバックアップを取得してから長い時間が経過している場合、適用に時間を要する可能性があります。
    </para>

doc/src/sgml/high-availability.sgml

@@ -3016,8 +3016,8 @@ WALに記録された操作はすでにプライマリで発生したもので
 しかし、スタンバイ側で行うべき問い合わせをプライマリサーバ上で直接実行することと比べ、こうしたクリーンアップに関する問題を優先する価値はありません。
 また、スタンバイに実行負荷を分散できるという利点があります。
 スタンバイサーバが接続、切断を頻繁に繰り返す場合、<varname>hot_standby_feedback</varname>によるフィードバックが提供されていなければ、その値を調整したいと思うでしょう。
-例えば、<varname>max_standby_archive_delay</varname>が増大し、切断している期間WALアーカイブファイルのコンフリクト発生による問い合わせの中断が速やかに行われないことを考えてみてください。
-また、再接続後に速やかに問い合わせが中断されることを避けるために<varname>max_standby_streaming_delay</varname>を大きくすることを考えてみてください。
+例えば、<varname>max_standby_archive_delay</varname>を増やし、接続をしていない間、WALアーカイブファイルのコンフリクトによって問い合わせの急速な中断が起きないようにすることを考慮してください。
+また、再接続後に新しく到着したストリーミングWALエントリによる急速な中断が起きることを避けるために<varname>max_standby_streaming_delay</varname>を大きくすることを考えてみてください。
    </para>
 
    <para>