by GitHub Actions [skip ci]

Author: actions-user

current/html/backup-dump.html

@@ -337,7 +337,7 @@
      make 2 gigabyte chunks:
 </span>
 <code class="command">split</code>コマンドで結果を使用しているファイルシステムが受け付けられる大きさに分割することができます。
-例えば2メガバイトずつに分割するには次のようにします。
+例えば2ギガバイトずつに分割するには次のようにします。
 
 </p><pre class="programlisting">
 pg_dump <em class="replaceable"><code>dbname</code></em> | split -b 2G - <em class="replaceable"><code>filename</code></em>

current/html/continuous-archiving.html

@@ -511,7 +511,7 @@
 </span>
 <a class="xref" href="app-pgbasebackup.html" title="pg_basebackup"><span class="refentrytitle"><span class="application">pg_basebackup</span></span></a>を使用して増分バックアップを作成するには、<code class="literal">--incremental</code>オプションを指定します。
 <code class="literal">--incremental</code>の引数として、同じサーバの以前のバックアップへのバックアップマニフェストを指定する必要があります。
-作成されたバックアップには、リレーション以外のファイルはそのまま含まれますが、一部のリレーションファイルは、以前のバックアップから変更されたブロックと、ファイルの現在のバージョンを再構築するのに十分なメタデータのみを含む、より小さな増分ファイルに置き換えられる場合があります。
+作成されたバックアップには、リレーション以外のファイルはそのまま含まれますが、一部のリレーションファイルは、以前のバックアップ以降に変更されたブロックのみと、ファイルの現在のバージョンを再構築するのに十分なメタデータを含む、より小さな増分ファイルに置き換えられる場合があります。
    </p><p>
 <span class="original">
     To figure out which blocks need to be backed up, the server uses WAL
@@ -847,7 +847,7 @@
 もし、スタンバイを作成するためのバックアップを続けて使用すると、スタンバイのWALファイルの保持を無制限に保留する結果になり、ホットスタンバイからのフィードバックを有効にしている場合、プライマリのWALを膨張させます。
 これは、これらのレプリケーションスロットを使っているクライアントはまだ、スタンバイではなく、プライマリのスロットを接続し続け、更新しているからです。
 バックアップが新しいプライマリを作成するためだけに作成されたとしても、レプリケーションスロットをコピーすることは特に有益であるとは考えられません。
-このようにバックアップにレプリケーションスロットを含むことは、新しいプライマリがオンラインになったときにはスロットの内容が期限切れしており、有害である可能性があります。
+このようにバックアップにレプリケーションスロットを含むことは、新しいプライマリがオンラインになる頃には、スロットの内容がかなり古くなっている可能性があります。
    </p><p>
 <span class="original">
     The contents of the directories &lt;filename&gt;pg_dynshmem/&lt;/filename&gt;,
@@ -969,7 +969,7 @@
 増分バックアップをリストアする場合は、増分バックアップと、それが直接または間接的に依存している以前のすべてのバックアップを、リストアを実行しているマシンにリストアする必要があります。
 これらのバックアップは、実行中のサーバが最終的に目的とするターゲットディレクトリではなく、別のディレクトリに配置する必要があります。
 これが完了したら、<a class="xref" href="app-pgcombinebackup.html" title="pg_combinebackup"><span class="refentrytitle"><span class="application">pg_combinebackup</span></span></a>を使用して完全バックアップとすべての増分バックアップからデータを抽出し、合成された完全バックアップをターゲットディレクトリに書き出します。
-上記のように、権限とテーブルスペースのリンクが正しいことを確認します。
+上記のように、権限とテーブル空間のリンクが正しいことを確認します。
     </p></li><li class="listitem"><p>
 <span class="original">
      Remove any files present in &lt;filename&gt;pg_wal/&lt;/filename&gt;; these came from the
@@ -1398,7 +1398,7 @@
      undesirable.  To avoid this risk, it is best not to modify any
      template databases while taking a base backup.
 </span>
-もしもベースバックアップが行われている時、<a class="link" href="sql-createdatabase.html" title="CREATE DATABASE"><code class="command">CREATE DATABASE</code></a>コマンドが実行され、ベースバックアップが処理を実行している期間に<code class="command">CREATE DATABASE</code>がコピーしているtemplateデータベースが変更されると、復旧処理はこれらの変更を作成されたデータベースにも同時に伝播させることは確実です。
+もしもベースバックアップが行われている時、<a class="link" href="sql-createdatabase.html" title="CREATE DATABASE"><code class="command">CREATE DATABASE</code></a>コマンドが実行され、ベースバックアップが処理を実行している期間に<code class="command">CREATE DATABASE</code>がコピーしているtemplateデータベースが変更されると、復旧処理により、これらの変更が作成されたデータベースにも伝播される可能性があります。
 もちろん、これは望まれる事ではありません。
 この危険を回避するには、ベースバックアップ期間中にはすべてのtemplateデータベースを変更しないことが一番です。
     </p></li><li class="listitem"><p>
@@ -1417,7 +1417,7 @@
 <a class="link" href="sql-createtablespace.html" title="CREATE TABLESPACE"><code class="command">CREATE TABLESPACE</code></a>コマンドはリテラルの絶対パス付でWALにログが記録され、したがって、同じ絶対パスでのテーブル空間作成の時に再生されます。
 これは、もしWALが異なったマシン上で再生される場合には好ましくありません。
 WAL再生がたとえ同一のマシンであっても、新規のデータディレクトリであれば危険です。
-なぜなら、再生は元のテーブル空間の内容を上書きし続けるからです。
+なぜなら、再生は元のテーブル空間の内容を上書きしてしまうからです。
 この種の潜在的な振舞いを防ぐためには、テーブル空間を作成もしくは削除後に新規ベースバックアップを行うのが最良の手段です。
     </p></li></ul></div><p>
    </p><p>

current/postgres-A4.pdf

@@ -7,7 +7,7 @@ layout: default
 
 ## 最新
 
-last-updated: 2025-07-29 04:30:42 JST
+last-updated: 2025-08-01 04:32:26 JST
 
 ### 最新 PostgreSQL