Merge pull request #3183 from noborus/forward-port-16-2

16からのフォワードポート（２）

doc/src/sgml/backup.sgml

@@ -96,7 +96,7 @@ pg_dump <replaceable class="parameter">dbname</replaceable> &gt; <replaceable cl
 ということは、データベースに接続可能なあらゆるリモートホストからこのバックアップ手順を実行できます。
 しかし、<application>pg_dump</application>は特別な権限で実行される訳ではないことを忘れないでください。
 特に、バックアップを行う全てのテーブルに対して読み取り権限が必要ですので、データベース全体のバックアップを実行する場合、ほとんど常にデータベースのスーパーユーザとして実行しなければなりません。
-(もしデータベース全体のバックアップを取るのに十分な権限を持っていない場合には、<option>-n <replaceable>schema</replaceable></option>もしくは、<option>-t <replaceable>table</replaceable></option>のようなオプションを使って、データベースのアクセス権のある部分をバックアップできます。)
+（もしデータベース全体のバックアップを取るのに十分な権限を持っていない場合には、<option>-n <replaceable>schema</replaceable></option>もしくは、<option>-t <replaceable>table</replaceable></option>のようなオプションを使って、データベースのアクセス権のある部分をバックアップできます。）
   </para>
 
   <para>
@@ -113,7 +113,7 @@ pg_dump <replaceable class="parameter">dbname</replaceable> &gt; <replaceable cl
 -->
 <application>pg_dump</application>を行うデータベースサーバを特定するにはコマンドラインの<option>-h <replaceable>host</replaceable></option>オプションと<option>-p <replaceable>port</replaceable></option>オプションを使用します。
 デフォルトのホストはローカルホスト、または<envar>PGHOST</envar>環境変数で指定したものです。
-同様に、デフォルトのポートは<envar>PGPORT</envar>環境変数で指定されているか、うまく行かない場合にはコンパイル時の設定がデフォルトとなります（そこはうまくできていて、サーバは通常コンパイル時の設定をデフォルトとします）。
+同様に、デフォルトのポートは<envar>PGPORT</envar>環境変数で指定されているか、うまく行かない場合にはコンパイル時の設定がデフォルトとなります。（そこはうまくできていて、サーバは通常コンパイル時の設定をデフォルトとします。）
   </para>
 
   <para>
@@ -158,7 +158,8 @@ pg_dump <replaceable class="parameter">dbname</replaceable> &gt; <replaceable cl
 -->
 <application>pg_dump</application>で作成されたダンプは、内部的に整合性があります。
 つまり、ダンプは<application>pg_dump</application>が開始された際のデータベースのスナップショットを示しています。
-<application>pg_dump</application>の操作はデータベースに対する他の作業を妨げません（<command>ALTER TABLE</command>のほとんどの形態であるような排他的ロックが必要な作業は例外です）。
+<application>pg_dump</application>の操作はデータベースに対する他の作業を妨げません。
+（<command>ALTER TABLE</command>のほとんどの形態であるような排他的ロックが必要な作業は例外です。）
   </para>
 
   <sect2 id="backup-dump-restore">
@@ -209,8 +210,8 @@ psql <replaceable class="parameter">dbname</replaceable> &lt; <replaceable class
     (Sometimes this is what you want, but usually it is not.)
 -->
 SQLダンプのリストアを実行する前に、ダンプされたデータベース内のオブジェクトを所有するユーザやそのオブジェクト上に権限を与えられたユーザも存在しなければなりません。
-存在していない場合、リストアはそのオブジェクトの元々の所有権や付与された権限を再作成することができません
-（このようにしたい場合もあるでしょうが、通常そうではありません）。
+存在していない場合、リストアはそのオブジェクトの元々の所有権や付与された権限を再作成することができません。
+（このようにしたい場合もあるでしょうが、通常そうではありません。）
    </para>
 
    <para>
@@ -705,7 +706,7 @@ tar -cf backup.tar /usr/local/pgsql/data
 -->
 ファイルシステムをバックアップするその他の選択肢として<application>rsync</application>の使用が挙げられます。
 これを行うには、先ずデータベースサーバが稼働中に<application>rsync</application>を実行し、そして<command>rsync --checksum</command>を実行するのに充分な間だけデータベースサーバを停止します。
-(<command>rsync</command>はファイルの更新時刻に関して1秒の粒度しかありませんので、<option>--checksum</option>が必要です。)
+（<command>rsync</command>はファイルの更新時刻に関して1秒の粒度しかありませんので、<option>--checksum</option>が必要です。）
 次の<application>rsync</application>は、比較的転送するデータ量が少なく、サーバが稼働していないため最終結果に矛盾がない事から、最初の<application>rsync</application>よりも迅速です。
 この方法で最小の稼働停止時間でファイルシステムのバックアップを行う事ができます。
   </para>
@@ -973,9 +974,9 @@ archive_command = 'copy "%p" "C:\\server\\archivedir\\%f"'  # Windows
     <literal>%p</literal> and <literal>%f</literal> parameters have been replaced,
     the actual command executed might look like this:
 -->
-これは、アーカイブ可能なWALセグメントを<filename>/mnt/server/archivedir</filename>ディレクトリにコピーします
+これは、アーカイブ可能なWALセグメントを<filename>/mnt/server/archivedir</filename>ディレクトリにコピーします。
 （これは一例です。
-推奨するものではなく、また、全てのプラットフォームで動作しない可能性があります）。
+推奨するものではなく、また、全てのプラットフォームで動作しない可能性があります。）
 <literal>%p</literal>および<literal>%f</literal>パラメータが置き換えられたあと、実行された実コマンドは以下のようになります。
 <programlisting>
 test ! -f /mnt/server/archivedir/00000001000000A900000065 &amp;&amp; cp pg_wal/00000001000000A900000065 /mnt/server/archivedir/00000001000000A900000065
@@ -1627,7 +1628,7 @@ SELECT * FROM pg_backup_stop(wait_for_archive => true);
      then the backup might not include all of the WAL files and will
      therefore be incomplete and not able to be restored.
 -->
-バックアップに必要なすべてのWALセグメントファイルのアーカイブが成功したことを、バックアップ作業の中で監視して確認するのであれば、<literal>wait_for_archive</literal>パラメータ(デフォルトでtrueです)をfalseに設定し、バックアップレコードがWALに書き込まれたら即座に<function>pg_backup_stop</function>が戻るようにすることができます。
+バックアップに必要なすべてのWALセグメントファイルのアーカイブが成功したことを、バックアップ作業の中で監視して確認するのであれば、<literal>wait_for_archive</literal>パラメータ（デフォルトでtrueです）をfalseに設定し、バックアップレコードがWALに書き込まれたら即座に<function>pg_backup_stop</function>が戻るようにすることができます。
 デフォルトでは、<function>pg_backup_stop</function>はすべてのWALがアーカイブされるのを待つので、少し時間がかかることがあります。
 このオプションは慎重に使わなければなりません。
 WALのアーカイブを適切に監視していない場合、バックアップにはすべてのWALファイルが含まれず、不完全かもしれません。
@@ -1702,7 +1703,7 @@ GNUの <application>tar</application>で1.23以降のバージョンを使用し
 <filename>pg_wal/</filename>がクラスタディレクトリ外のどこかを指し示すシンボリックリンクの場合は調整が簡単です。
 これは性能上の理由でよく使用される設定です。
 また、いずれこのバックアップを使う<application>postmaster</application>ではなく、今起動している<application>postmaster</application>の情報を記録している<filename>postmaster.pid</filename>と<filename>postmaster.opts</filename>も除外できます。
-(これらのファイルは<application>pg_ctl</application>を誤作動させる可能性があります。)
+（これらのファイルは<application>pg_ctl</application>を誤作動させる可能性があります。）
    </para>
 
    <para>
@@ -2009,7 +2010,7 @@ restore_command = 'cp /mnt/server/archivedir/%f %p'
 このコマンドが失敗した時に非ゼロの終了ステータスを返すことが重要です。
 このコマンドは、アーカイブに存在しないファイルを要求する<emphasis>かもしれません</emphasis>が、その場合でも非ゼロを返さなければなりません。
 これはエラー状態ではありません。
-例外は、コマンドがシグナルによって中断された場合(データベースの停止に使用される<systemitem>SIGTERM</systemitem>以外)か、シェルによるエラー(コマンドが見つかりませんなど)で復旧が中断され、サーバが起動しない場合です。
+例外は、コマンドがシグナルによって中断された場合（データベースの停止に使用される<systemitem>SIGTERM</systemitem>以外）か、シェルによるエラー（コマンドが見つかりませんなど）で復旧が中断され、サーバが起動しない場合です。
    </para>
 
    <para>
@@ -2086,8 +2087,8 @@ restore_command = 'cp /mnt/server/archivedir/%f %p'
       and roll forward from there.)
 -->
 停止時点はバックアップの終了時刻、つまり、<function>pg_backup_stop</function>の最終時刻より後の時点でなければなりません。
-バックアップを行っている最中のある時点までベースバックアップを使用して復旧させることはできません
-（こうした時点まで復旧させるには、その前のベースバックアップまで戻って、そこからロールフォワードしてください）。
+バックアップを行っている最中のある時点までベースバックアップを使用して復旧させることはできません。
+（こうした時点まで復旧させるには、その前のベースバックアップまで戻って、そこからロールフォワードしてください。）
      </para>
    </note>
 
@@ -2476,8 +2477,8 @@ WAL再生がたとえ同一のマシンであっても、新規のデータデ
 これらのページスナップショットは、クラッシュから回復のために設計されています。
 それというのも、回復処理の際には不完全に書き込まれているディスクページを修復しなければならないことがあるからです。
 システムのハードウェアやソフトウェアによっては、不完全なディスクページの書き込みが起きてしまう危険性は無視してもよい程微小です。
-この場合<xref linkend="guc-full-page-writes"/>パラメータを設定してページスナップショットを無効にすることで、アーカイブされたWALの総容量を大幅に縮小できます
-（実際に設定を行う前に、<xref linkend="wal"/>の注意事項と警告を読んでください）。
+この場合<xref linkend="guc-full-page-writes"/>パラメータを設定してページスナップショットを無効にすることで、アーカイブされたWALの総容量を大幅に縮小できます。
+（実際に設定を行う前に、<xref linkend="wal"/>の注意事項と警告を読んでください。）
 ページスナップショットを無効にしても PITR処理の際にWALが使用できなくなることはありません。
 将来の課題は、<varname>full_page_writes</varname>がたとえオンになっている場合であっても不要なページを取り除き、アーカイブ済みWALデータの圧縮を行うことでしょう。
 差し当たり管理者は、可能な限りチェックポイント間隔パラメータを大きくすることによって、WALに含まれるページスナップショットの数を削減することができます。

doc/src/sgml/brin.sgml

@@ -64,7 +64,7 @@
 すなわち、インデックス内のレンジ要約情報が検索条件と<firstterm>一致</firstterm>すれば、<acronym>BRIN</acronym>インデックスは、レンジ内の全タプルを返します。
 クエリエグゼキュータの役割は、検索条件を再チェックし、条件に合致しないタプルを捨てることです。
 つまり言い換えると、<acronym>BRIN</acronym>インデックスには損失性があります。
-<acronym>BRIN</acronym>インデックスは非常に小さいため、それに対するスキャンは順スキャンに比べると小さなオーバーヘッドしか与えません。しかし、あらかじめ条件に合致しないと分かっているテーブルの多くの部分をスキャンすることを避けることができます。
+<acronym>BRIN</acronym>インデックスは非常に小さいため、それに対するスキャンはシーケンシャルスキャンに比べると小さなオーバーヘッドしか与えません。しかし、あらかじめ条件に合致しないと分かっているテーブルの多くの部分をスキャンすることを避けることができます。
  </para>
 
  <para>

doc/src/sgml/btree.sgml

@@ -540,7 +540,7 @@ returns bool
 -->
 このように実行する前に、本関数は、<replaceable>offset</replaceable>の符号を検査すべきです。
 すなわち、負であったなら、エラー<literal>ERRCODE_INVALID_PRECEDING_OR_FOLLOWING_SIZE</literal>(22013)、エラー文面としては<quote>invalid preceding or following size in window function(ウィンドウ関数で先行または後続のサイズが不正です)</quote>などを出すことです。
-（意味上の必要性が乏しいと見られることから非標準の演算子族はこの制限を無視することを選ぶかもしれませんが、これはSQL標準で必要とされています。）
+（意味上の必要性が乏しいと見られることから非標準の演算子族はこの制限を無視することを選ぶかもしれませんが、これは標準SQLで必要とされています。）
 中核コードが特定のデータ型における<quote>ゼロより小さい</quote>ことの意味を理解しなくても良いように、この要件は<function>in_range</function>関数に委託されます。
     </para>
 
@@ -886,6 +886,7 @@ B-treeはGiST、SP-GiST、GINおよびBRINで行われているような柔軟
 一つのメタページがインデックスの最初のセグメントファイルの固定位置に格納されます。
 それ以外の全てのページはリーフページか内部ページのいずれかです。
 リーフページはツリーの最下階層にあるページです。
+それ以外の全ての階層は内部ページで構成されます。
 各リーフページはテーブルの行を指すタプルを含みます。
 各内部ページはツリーの次の下位層を指すタプルを含みます。
 典型的には、全ページの99％以上がリーフページです。
@@ -978,7 +979,7 @@ B-Treeインデックスは、MVCCの下で同じ論理テーブル行の複数
    thresholds are exceeded (see <xref linkend="autovacuum"/>).
 -->
 B-Treeインデックスは、<firstterm>ボトムアップインデックスの削除</firstterm>パスの実行によって、バージョンチャーンのインデックスタプルを徐々に削除します。
-各削除パスは、予期された<quote>バージョンチャーンのページ分割</quote>に対してトリガーされます。
+各削除パスは、予期された<quote>バージョンチャーンのページ分割</quote>に対してトリガされます。
 これは、<command>UPDATE</command>文によって論理的に変更されてないインデックスだけで発生します。
 さもないと、特定のページで使われなくなったバージョンが集中的に蓄積されます。
 ある種の実装レベルの発見的手法は、均一のごみインデックスタプルの特定及び削除に失敗する可能がありますが、ページの分割は通常避けることができます（ページ分割もしくは重複排除パスの場合に、リーフページ上の収まらない新しいタプルが入ることの問題が解決します）。
@@ -1143,6 +1144,7 @@ B-Tree重複排除は、B-Tree演算子クラスの<literal>=</literal>項に従
 GINのポスティングリストのタプルと違って、B-Treeのポスティングリストのタプルは新たな重複が挿入される度に拡張する必要がありません。それらはリーフページの元の論理内容に対する単なる代替の物理表現にすぎません。
 この設計は読み書き混合のワークロードでの性能の一貫性を重視しています。
 ほとんどのクライアントアプリケーションは重複排除を使うことで少なくとも控えめな性能の恩恵を確認することができるでしょう。
+重複排除はデフォルトで有効になっています。
   </para>
   <para>
 <!--
@@ -1179,7 +1181,7 @@ GINのポスティングリストのタプルと違って、B-Treeのポステ
 -->
 インデックスの値に重複が無いか殆ど無いために重複排除から利益を得られない、書き込みの多いワークロードには、（重複排除が明示的に無効化されて居ない限り）固定のペナルティによる小さい負荷増があります。
 <literal>deduplicate_items</literal>格納パラメータは個別のインデックス内で重複排除を無効化するのに使うことができます。
-ポスティングリストタプルの読み込みは少なくとも通常タプル表現の読み込み程度に効率的であるため、読み込みのみのワークロードで性能ペナルティは一切ありません
+ポスティングリストタプルの読み込みは少なくとも通常タプル表現の読み込み程度に効率的であるため、読み込みのみのワークロードで性能ペナルティは一切ありません。
 通常は重複排除を無効化することは有益ではありません。
   </para>
   <para>