diff --git a/.ng.list b/.ng.list
index 3d9a4effd56..0015de44469 100644
--- a/.ng.list
+++ b/.ng.list
@@ -35,4 +35,5 @@
 オーバ[^ー]
 ワーカ[^ー]
 スーパ[^ー]
-トランザクション隔離レベル
\ No newline at end of file
+トランザクション隔離レベル
+稼動
\ No newline at end of file
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index bc0011c0778..7b6bd9ed9a6 100644
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -650,7 +650,7 @@ tar -cf backup.tar /usr/local/pgsql/data
 -->
 その他のファイルシステムバックアップ方法として、ファイルシステムが<quote>整合性を維持したスナップショット</quote>機能をサポートしている場合（かつ、正しく実装されていると信用する場合）、データディレクトリのスナップショットを作成する方法があります。
 典型的な手順では、データベースを含むボリュームの<quote>凍結スナップショット</quote>を作成し、データディレクトリ全体（上述のように、一部だけではいけません）をスナップショットからバックアップデバイスにコピーし、そして、凍結スナップショットを解放します。
-これはデータベースサーバが稼動中であっても動作します。
+これはデータベースサーバが稼働中であっても動作します。
 しかし、こうして作成されたバックアップは、データベースサーバが適切に停止されなかった状態のデータベースファイルを保存します。
 そのため、このバックアップデータでデータベースサーバを起動する時、直前のサーバインスタンスがクラッシュしたものとみなされ、WALログが取り直されます。
 これは問題ではありません。
@@ -995,7 +995,7 @@ test ! -f /mnt/server/archivedir/00000001000000A900000065 &amp;&amp; cp pg_wal/0
     protected from prying eyes; for example, archive into a directory that
     does not have group or world read access.
 -->
-このアーカイブ用コマンドは<productname>PostgreSQL</productname>サーバを稼動させるユーザと同じ所有権で実行されます。
+このアーカイブ用コマンドは<productname>PostgreSQL</productname>サーバを稼働させるユーザと同じ所有権で実行されます。
 アーカイブされる一連のWALファイルには、実質、データベース内の全てが含まれていますので、アーカイブしたデータをのぞき見から確実に保護しなければならないでしょう。
 例えば、グループや全員に読み込み権限を付与していないディレクトリにデータをアーカイブしてください。
    </para>
@@ -1674,7 +1674,7 @@ GNUの <application>tar</application>で1.23以降のバージョンを使用し
 <!--
      Stop the server, if it's running.
 -->
-もし稼動しているのであればサーバを停止してください。
+もし稼働しているのであればサーバを停止してください。
     </para>
    </listitem>
    <listitem>
diff --git a/doc/src/sgml/charset.sgml b/doc/src/sgml/charset.sgml
index b9f2342ba25..485cba4d1fd 100644
--- a/doc/src/sgml/charset.sgml
+++ b/doc/src/sgml/charset.sgml
@@ -266,7 +266,7 @@ Windowsは、<literal>German_Germany</literal>や<literal>Swedish_Sweden.1252</l
     appear in different languages depending on where they originated.
 -->
 サーバのロケールの動作はどのクライアントの環境にも依存せず、サーバが参照できる環境変数で決まります。
-ですからサーバを稼動させる前に正しいロケール設定を行うように注意してください。
+ですからサーバを稼働させる前に正しいロケール設定を行うように注意してください。
 結果としてサーバとクライアントで異なるロケールが設定されていると、メッセージはそれらがどこから生じたかによって、異なる言語で表示されます。
    </para>
 
diff --git a/doc/src/sgml/config0.sgml b/doc/src/sgml/config0.sgml
index 8ed58dc95b6..580ec66cc4a 100644
--- a/doc/src/sgml/config0.sgml
+++ b/doc/src/sgml/config0.sgml
@@ -2892,7 +2892,7 @@ Linuxでは、これは<quote>transparent huge pages</quote><indexterm><primary>
         too high.  It may be useful to control for this by separately
         setting <xref linkend="guc-autovacuum-work-mem"/>.
 -->
-自動バキュームが稼動すると、最大でこのメモリの<xref linkend="guc-autovacuum-max-workers"/>倍が配分されるので、デフォルトの値をあまり高く設定しないよう注意してください。
+自動バキュームが稼働すると、最大でこのメモリの<xref linkend="guc-autovacuum-max-workers"/>倍が配分されるので、デフォルトの値をあまり高く設定しないよう注意してください。
 別の設定項目<xref linkend="guc-autovacuum-work-mem"/>で制御するのが良いかもしれません。
        </para>
        <para>
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 4a5d5f5ec92..d5f7fcb87d9 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -35,9 +35,9 @@
   server has to be propagated to all servers so that future read
   requests to those servers return consistent results.
 -->
-データベースサーバは共同して稼動できます。
+データベースサーバは共同して稼働できます。
 その目的は、最初のサーバが故障したとき次のサーバへ速やかに引き継ぎができること（高可用性）および複数のコンピュータが同一のデータを処理できること（負荷分散）です。
-データベースサーバがシームレスに共同稼動できれば理想的です。
+データベースサーバがシームレスに共同稼働できれば理想的です。
 静的なウェブページを提供するウェブサーバは、ウェブからの要求で生ずる負荷を複数のマシンに分散するだけで、簡単に結合できます。
 実際、読み取り専用のデータベースサーバの結合は、同じようにかなり容易です。
 しかし、大部分のデータベースサーバは、読み書きの混在した要求を受け取り、読み書き両用のサーバの結合はとても困難です。
@@ -54,7 +54,7 @@
   problem in a different way, and minimizes its impact for a specific
   workload.
 -->
-この同時性を持たせるという問題は、共同して稼動するサーバにおいて根本的に困難なものです。
+この同時性を持たせるという問題は、共同して稼働するサーバにおいて根本的に困難なものです。
 すべての使用状況において、単一の解法を用いて同時性の問題の影響を軽減できないため、複数の解法が存在します。
 各々の解法はこの問題に異なったやり方を適用し、固有の作業負荷に対する影響を最小化します。
  </para>
@@ -156,7 +156,7 @@
 -->
 データベースのコピーを 1つだけ保有すればよいため、共有ディスクを用いたフェイルオーバーは同期によるオーバーヘッドを回避できます。
 本解法では、複数のサーバが単一のディスクアレイを共有します。
-主データベースサーバが故障したとき、まるでデータベースの破損から復旧したように、スタンバイサーバが元のデータベースを実装して稼動できます。
+主データベースサーバが故障したとき、まるでデータベースの破損から復旧したように、スタンバイサーバが元のデータベースを実装して稼働できます。
 これはデータの消失がない高速なフェイルオーバーを行うことができます。
     </para>
 
@@ -175,7 +175,7 @@
 ネットワークファイルシステムの利用も可能ですが、そのファイルシステムが<acronym>POSIX</acronym>仕様を満たしているか注意してください。
 （ <xref linkend="creating-cluster-nfs"/>を見てください）。
 本解法には重大な制約があり、共有ディスクアレイが故障または破損したとき、プライマリサーバもスタンバイサーバも機能しなくなります。
-また、プライマリサーバが稼動している間は、スタンバイサーバが共有記憶装置にアクセスしてはなりません。
+また、プライマリサーバが稼働している間は、スタンバイサーバが共有記憶装置にアクセスしてはなりません。
     </para>
 
    </listitem>
@@ -309,7 +309,7 @@ protocol to make nodes agree on a serializable transactional order.
      servers.  Because it updates the standby server asynchronously (in
      batches), there is possible data loss during fail over.
 -->
-この種類のレプリケーションの一例は<productname>Slony-I</productname>であり、テーブル単位の粒度を持ち、複数のスタンバイサーバが稼動できます。
+この種類のレプリケーションの一例は<productname>Slony-I</productname>であり、テーブル単位の粒度を持ち、複数のスタンバイサーバが稼働できます。
 （バッチ処理によって）スタンバイサーバのデータを非同期で更新するため、フェイルオーバーにおけるデータ消失の可能性があります。
     </para>
    </listitem>
@@ -332,7 +332,7 @@ protocol to make nodes agree on a serializable transactional order.
      among them.
 -->
 SQLに基づいたレプリケーションのミドルウェアでは、プログラムがすべてのSQL問い合わせを採取して、1つまたはすべてのサーバに送付します。
-なお、各々のサーバは独立して稼動します。
+なお、各々のサーバは独立して稼働します。
 読み書き問い合わせは、すべてのサーバがすべての変更を受け取るように全サーバに送付されなければなりません。
 しかし、読み取り専用の問い合わせはサーバ全体の読み取り負荷を分散させるために、1つのサーバだけに送付することができます。
     </para>
@@ -354,7 +354,7 @@ SQLに基づいたレプリケーションのミドルウェアでは、プロ
      are examples of this type of replication.
 -->
 問い合わせを修正しないで送付した場合、<function>random()</function>関数による乱数値と<function>CURRENT_TIMESTAMP</function>関数による現在時刻およびシーケンス値が、サーバごとに異なることがあります。
-その理由は、各サーバが独立して稼動しているため、および、実際のデータ変更ではなくSQL問い合わせが送信されるからです。
+その理由は、各サーバが独立して稼働しているため、および、実際のデータ変更ではなくSQL問い合わせが送信されるからです。
 これが許容できない場合は、ミドルウェアかアプリケーションで単一のソースからそのような値を確定し、その結果を書き込み問い合わせで使用しなければなりません。
 トランザクションをコミットするか中断するかについても、全サーバが同一となるよう注意しなければなりません。
 これには2相コミット（<xref linkend="sql-prepare-transaction"/>および<xref linkend="sql-commit-prepared"/>）を使用することになるでしょう。
@@ -382,7 +382,7 @@ SQLに基づいたレプリケーションのミドルウェアでは、プロ
      Bucardo is an example of this type of replication.
 -->
 ラップトップやリモートマシンのように、通常は接続されていない、あるいは遅い通信リンクで接続されているサーバ間において、データの一貫性を保持することは挑戦的な課題です。
-非同期マルチマスタレプリケーションの使用により、全サーバの独立した稼動、およびトランザクションの衝突を識別するための定期的な通信を実現します。
+非同期マルチマスタレプリケーションの使用により、全サーバの独立した稼働、およびトランザクションの衝突を識別するための定期的な通信を実現します。
 トランザクションの衝突は、利用者および衝突回避法によって解決できるでしょう。
 Bucardoはこの種のレプリケーションの一例です。
     </para>
@@ -831,7 +831,7 @@ Bucardoはこの種のレプリケーションの一例です。
    replication solutions. This configuration also has relatively low
    performance impact on the primary server.
 -->
-プライマリサーバとスタンバイサーバは、この機能を提供するために共同して稼動しますが、サーバとサーバはゆるく結合しています。
+プライマリサーバとスタンバイサーバは、この機能を提供するために共同して稼働しますが、サーバとサーバはゆるく結合しています。
 プライマリサーバは継続的アーカイブモードで動作し、各スタンバイサーバはプライマリからWALファイルを読み取る、継続的リカバリモードで動作します。
 この機能を可能にするために、データベースのテーブル変更は不要です。
 したがって、他のレプリケーションの解法に比べて、管理にかかるオーバーヘッドが減少します。
@@ -1361,7 +1361,7 @@ WALから機密情報を取り出すことは簡単だからです。
      <filename>pg_hba.conf</filename> file on the primary:
 -->
 レプリケーション用のクライアント認証は<filename>pg_hba.conf</filename>内でその<replaceable>database</replaceable>フィールドに<literal>replication</literal>を指定したレコードで制御されます。
-例えば、スタンバイがIPアドレス<literal>192.168.1.100</literal>のホストで稼動し、レプリケーション用のアカウントの名前が<literal>foo</literal>である場合、管理者はプライマリ上の<filename>pg_hba.conf</filename>に以下の行を追加することができます。
+例えば、スタンバイがIPアドレス<literal>192.168.1.100</literal>のホストで稼働し、レプリケーション用のアカウントの名前が<literal>foo</literal>である場合、管理者はプライマリ上の<filename>pg_hba.conf</filename>に以下の行を追加することができます。
 
 <programlisting>
 <!--
@@ -1390,14 +1390,14 @@ host    replication     foo             192.168.1.100/32        md5
 -->
 プライマリサーバのホスト名とポート番号、接続する利用者名およびパスワードは、<xref linkend="guc-primary-conninfo"/>で指定します。
 パスワードはスタンバイサーバの<filename>~/.pgpass</filename>ファイルでも設定できます（<replaceable>database</replaceable>フィールドの<literal>replication</literal>を指定します）。
-例えば、プライマリサーバが稼動するホストの IP アドレスが<literal>192.168.1.50</literal>でポート番号が<literal>5432</literal>であり、レプリケーションのアカウント名が<literal>foo</literal>であり、パスワードが<literal>foopass</literal>である場合、管理者はスタンバイサーバの<filename>postgresql.conf</filename>ファイルに次行を追加できます。
+例えば、プライマリサーバが稼働するホストの IP アドレスが<literal>192.168.1.50</literal>でポート番号が<literal>5432</literal>であり、レプリケーションのアカウント名が<literal>foo</literal>であり、パスワードが<literal>foopass</literal>である場合、管理者はスタンバイサーバの<filename>postgresql.conf</filename>ファイルに次行を追加できます。
 
 <programlisting>
 <!--
 # The standby connects to the primary that is running on host 192.168.1.50
 # and port 5432 as the user "foo" whose password is "foopass".
 -->
-# プライマリサーバが 192.168.1.50 のホストの 5432ポートで稼動し
+# プライマリサーバが 192.168.1.50 のホストの 5432ポートで稼働し
 # 利用者名が foo でパスワードが foopass とする
 primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
 </programlisting>
@@ -2865,7 +2865,7 @@ WALに記録された操作はすでにプライマリで発生したもので
 この問題の例として、スタンバイサーバで現在問い合わせ対象となっているテーブルをプライマリサーバで<command>DROP TABLE</command>を行う管理者を考えてみます。
 スタンバイで<command>DROP TABLE</command>が適用されたら問い合わせを継続できないことは明確です。
 プライマリ上でこうした状況が発生した場合は、他の問い合わせが終わるまで<command>DROP TABLE</command>は待機させられます。
-しかし、<command>DROP TABLE</command>がプライマリで実行された時、プライマリ側でスタンバイで稼動する問い合わせに関する情報がありませんので、スタンバイ側のこうした問い合わせを待機させることはできません。
+しかし、<command>DROP TABLE</command>がプライマリで実行された時、プライマリ側でスタンバイで稼働する問い合わせに関する情報がありませんので、スタンバイ側のこうした問い合わせを待機させることはできません。
 スタンバイ側で問い合わせが実行している時にWALの変更レコードがスタンバイに届けば、コンフリクトが発生します。
 スタンバイサーバはWALレコードの適用を遅延させる（およびその後の適用すべても遅延させる）か、<command>DROP TABLE</command>を適用できるようにコンフリクトする問い合わせを取り消すかのいずれかを行わなければなりません。
    </para>
@@ -3078,7 +3078,7 @@ WALに記録された操作はすでにプライマリで発生したもので
     To confirm the server has come up, either loop trying to connect from
     the application, or look for these messages in the server logs:
 -->
-<filename>postgresql.conf</filename>において<varname>hot_standby</varname>が<literal>on</literal>で（これはデフォルトです）、かつ<link linkend="file-standby-signal"><filename>standby.signal</filename></link><indexterm><primary>standby.signal</primary><secondary>ホットスタンバイのための</secondary></indexterm>が存在すれば、サーバはホットスタンバイモードで稼動します。
+<filename>postgresql.conf</filename>において<varname>hot_standby</varname>が<literal>on</literal>で（これはデフォルトです）、かつ<link linkend="file-standby-signal"><filename>standby.signal</filename></link><indexterm><primary>standby.signal</primary><secondary>ホットスタンバイのための</secondary></indexterm>が存在すれば、サーバはホットスタンバイモードで稼働します。
 しかし、サーバはまず問い合わせが実行できる程度の一貫性を持つ状態を提供するために十分なリカバリを完了させなければなりませんので、ホットスタンバイでの接続が有効になるまでに多少の時間がかかるかもしれません。
 サーバの準備ができたことを確認するために、アプリケーションで接続試行を繰り返すか、サーバログに以下のメッセージがあるかどうかを確認します。
 
@@ -3369,7 +3369,7 @@ HINT:  You can then restart the server after making the necessary configuration
     vacuum occurs on the standby.  Vacuums running on the primary
     do still send their changes to the standby.
 -->
-存在を検知する情報が単純なので、<productname>Nagios</productname>プラグイン<productname>check_pgsql</productname>は稼動します。
+存在を検知する情報が単純なので、<productname>Nagios</productname>プラグイン<productname>check_pgsql</productname>は稼働します。
 一部の報告値が異なった、混乱を招く結果となりますが、<productname>check_postgres</productname>の監視スクリプトも動作します。
 たとえば、スタンバイではバキュームが発生しないため、最終バキューム時刻は維持されません。
 それでも、プライマリで行われるバキュームはその変更をスタンバイに送信します。
@@ -3380,7 +3380,7 @@ HINT:  You can then restart the server after making the necessary configuration
     WAL file control commands will not work during recovery,
     e.g., <function>pg_backup_start</function>, <function>pg_switch_wal</function> etc.
 -->
-リカバリの間WALの制御コマンドは稼動しません。
+リカバリの間WALの制御コマンドは稼働しません。
 例えば、<function>pg_backup_start</function>や<function>pg_switch_wal</function>などです。
    </para>
 
@@ -3388,7 +3388,7 @@ HINT:  You can then restart the server after making the necessary configuration
 <!--
     Dynamically loadable modules work, including <structname>pg_stat_statements</structname>.
 -->
-<structname>pg_stat_statements</structname>も含み、動的に読み込み可能なモジュールは稼動します。
+<structname>pg_stat_statements</structname>も含み、動的に読み込み可能なモジュールは稼働します。
    </para>
 
    <para>
@@ -3400,7 +3400,7 @@ HINT:  You can then restart the server after making the necessary configuration
     and have it initiate a similar advisory lock on the standby. Advisory
     locks relate only to the server on which they are acquired.
 -->
-デッドロック検出を含むアドバイザリロックは、通常リカバリにおいて稼動します。
+デッドロック検出を含むアドバイザリロックは、通常リカバリにおいて稼働します。
 アドバイザリロックはWALに決して記録されないので、プライマリサーバでもスタンバイサーバでもWALの再実行においてコンフリクトが起こらないことに注意してください。
 プライマリサーバでアドバイザリロックを取得して、スタンバイサーバで同様のアドバイザリロックを掛けることはできません。
 アドバイザリロックは取得したサーバだけに関係するものです。
@@ -3416,8 +3416,8 @@ HINT:  You can then restart the server after making the necessary configuration
     standby to any system that requires additional database writes or
     relies on the use of triggers.
 -->
-<productname>Slony</productname>や<productname>Londiste</productname>や<productname>Bucardo</productname>のようにトリガに基づいたレプリケーションシステムは、スタンバイサーバで全く稼動しません。
-しかし、それによる変更がスタンバイサーバに送られるまでは、プライマリサーバにおいて問題なく稼動します。
+<productname>Slony</productname>や<productname>Londiste</productname>や<productname>Bucardo</productname>のようにトリガに基づいたレプリケーションシステムは、スタンバイサーバで全く稼働しません。
+しかし、それによる変更がスタンバイサーバに送られるまでは、プライマリサーバにおいて問題なく稼働します。
 WALの再実行はトリガに基づいたものではありません。
 したがって、データベースへの付加的な書き込みを必要とするか、トリガの使用に依存するものを、スタンバイサーバを中継して他のシステムへ送ることはできません。
    </para>
@@ -3510,7 +3510,7 @@ WALの再実行はトリガに基づいたものではありません。
     Autovacuum is not active during recovery.  It will start normally at the
     end of recovery.
 -->
-リカバリの間は自動バキュームは稼動しません。
+リカバリの間は自動バキュームは稼働しません。
 リカバリが終わると正常に起動します。
    </para>
 
@@ -3524,7 +3524,7 @@ WALの再実行はトリガに基づいたものではありません。
     The <command>CHECKPOINT</command> command is accepted during recovery,
     though it performs a restartpoint rather than a new checkpoint.
 -->
-リカバリの間、チェックポイントプロセスとバックグラウンドライタプロセスは稼動しています。
+リカバリの間、チェックポイントプロセスとバックグラウンドライタプロセスは稼働しています。
 チェックポイントプロセスは（プライマリサーバにおけるチェックポイントに類似した）リスタートポイントを設定し、通常のブロック消去を行います。
 これはスタンバイサーバに保存されるヒントビット情報の更新を含むことができます。
 リカバリの間<command>CHECKPOINT</command>コマンドは受理されますが、新規のチェックポイントではなくてリスタートポイントが設定されます。
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index d1a50942ff7..161297a48b2 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -1021,7 +1021,7 @@ PGPing PQpingParams(const char * const *keywords,
 <!--
            The server is running and appears to be accepting connections.
 -->
-サーバは稼動中で、接続を受け付けているようです。
+サーバは稼働中で、接続を受け付けているようです。
           </para>
          </listitem>
         </varlistentry>
@@ -1034,7 +1034,7 @@ PGPing PQpingParams(const char * const *keywords,
            The server is running but is in a state that disallows connections
            (startup, shutdown, or crash recovery).
 -->
-サーバは稼動中ですが、接続を許可しない状態（起動処理中、停止処理中、クラッシュリカバリ中）です。
+サーバは稼働中ですが、接続を許可しない状態（起動処理中、停止処理中、クラッシュリカバリ中）です。
           </para>
          </listitem>
         </varlistentry>
@@ -1051,7 +1051,7 @@ PGPing PQpingParams(const char * const *keywords,
            firewall blocking the connection request).
 -->
 サーバと通信できません。
-これは、サーバが稼動中ではない、指定した接続パラメータの何か（例えばポート番号の間違い）が間違っている、ネットワーク接続性の問題（例えば接続要求をブロックするファイアウォール）があることを示しているかもしれません。
+これは、サーバが稼働中ではない、指定した接続パラメータの何か（例えばポート番号の間違い）が間違っている、ネットワーク接続性の問題（例えば接続要求をブロックするファイアウォール）があることを示しているかもしれません。
           </para>
          </listitem>
         </varlistentry>
@@ -2570,7 +2570,7 @@ Server Name Indicationは、SSLストリームを復号化することなく接
         <xref linkend="auth-peer"/>.
 -->
 このパラメータは、例えば<literal>requirepeer=postgres</literal>のようにサーバのオペレーティングシステムのユーザ名を指定します。
-Unixドメインソケット接続を確立する時に、このパラメータが設定された場合、クライアントは接続開始時にサーバプロセスが指定されたユーザ名で稼動しているか検査し、稼動していない場合は接続をエラーとして中断します。
+Unixドメインソケット接続を確立する時に、このパラメータが設定された場合、クライアントは接続開始時にサーバプロセスが指定されたユーザ名で稼働しているか検査し、稼働していない場合は接続をエラーとして中断します。
 このパラメータは、TCP/IP接続においてSSL証明書で実現するようなサーバ認証を実現するために使用することができます。
 （Unixドメインソケットが<filename>/tmp</filename>などの誰にでも書き込むことができる場所にある場合、誰でもそこで接続を監視するサーバを起動できることに注意してください。
 信頼できるユーザが起動したサーバに接続することを確実に行うために、このパラメータを使用してください。）
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml
index fb7320975e0..44d7b81e056 100644
--- a/doc/src/sgml/ref/pg_basebackup.sgml
+++ b/doc/src/sgml/ref/pg_basebackup.sgml
@@ -46,7 +46,7 @@ PostgreSQL documentation
    and as the starting point for a log-shipping or streaming-replication standby
    server (see <xref linkend="warm-standby"/>).
 -->
-<application>pg_basebackup</application>は、稼動中の<productname>PostgreSQL</productname>のデータベースクラスタのベースバックアップを取るために使用されます。
+<application>pg_basebackup</application>は、稼働中の<productname>PostgreSQL</productname>のデータベースクラスタのベースバックアップを取るために使用されます。
 データベースへの他のクライアントに影響することなく、バックアップが取られます。
 また、このバックアップはポイントインタイムリカバリ（<xref linkend="continuous-archiving"/>参照）とログシッピングやストリーミングレプリケーションスタンバイサーバ用の開始点（<xref linkend="warm-standby"/>参照）としても使用できます。
   </para>
@@ -1382,7 +1382,7 @@ tar形式を使う場合、そのデータを使うPostgreSQLサーバを起動
    and store it in the local directory
    <filename>/usr/local/pgsql/data</filename>:
 -->
-<literal>mydbserver</literal>で稼動するサーバのベースバックアップを作成し、ローカルディレクトリ<filename>/usr/local/pgsql/data</filename>に保管します。
+<literal>mydbserver</literal>で稼働するサーバのベースバックアップを作成し、ローカルディレクトリ<filename>/usr/local/pgsql/data</filename>に保管します。
 <screen>
 <prompt>$</prompt> <userinput>pg_basebackup -h mydbserver -D /usr/local/pgsql/data</userinput>
 </screen>
diff --git a/doc/src/sgml/ref/pg_resetwal.sgml b/doc/src/sgml/ref/pg_resetwal.sgml
index c90ebe93c43..47d5a3e53b7 100644
--- a/doc/src/sgml/ref/pg_resetwal.sgml
+++ b/doc/src/sgml/ref/pg_resetwal.sgml
@@ -520,7 +520,7 @@ PostgreSQL documentation
    <command>pg_resetwal</command> to run.  But before you do
    so, make doubly certain that there is no server process still alive.
 -->
-このコマンドは、サーバの稼動中に使用してはいけません。
+このコマンドは、サーバの稼働中に使用してはいけません。
 <command>pg_resetwal</command>は、データディレクトリにサーバのロックファイルがあると、実行されません。
 サーバがクラッシュした場合、ロックファイルがそのまま残される場合があります。
 その場合は、ロックファイルを削除すれば<command>pg_resetwal</command>を実行することができます。
diff --git a/doc/src/sgml/ref/pgupgrade.sgml b/doc/src/sgml/ref/pgupgrade.sgml
index 352badd5b2d..42d79fa5a79 100644
--- a/doc/src/sgml/ref/pgupgrade.sgml
+++ b/doc/src/sgml/ref/pgupgrade.sgml
@@ -675,7 +675,7 @@ pg_upgrade.exe
 -->
 起動後、<command>pg_upgrade</command>は2つのクラスタに互換性があるかどうか検証し、その後、アップグレードを行います。
 検査のみを行う<command>pg_upgrade --check</command>を使用することができます。
-この場合は古いサーバは稼動中であっても構いません。
+この場合は古いサーバは稼働中であっても構いません。
 また<command>pg_upgrade --check</command>は、アップグレード後に手作業で行わなければならない調整作業があればその概要を示します。
 リンクまたは複製モードを使用する予定であれば、モード固有の検査を有効にするために<option>--check</option>を付けて<option>--link</option>または<option>--clone</option>オプションを使用すべきです。
 <command>pg_upgrade</command>は現在のディレクトリに対する書き込み権限を必要とします。
@@ -693,7 +693,7 @@ pg_upgrade.exe
 -->
 言うまでもありませんが、アップグレード中はクラスタにアクセスしてはいけません。
 意図しないクライアント接続を防ぐために、デフォルトでは<application>pg_upgrade</application>は50432ポートでサーバを稼働します。
-古いクラスタと新しいクラスタが同時に稼動することはありませんので、両クラスタで同じポート番号を使用することができます。
+古いクラスタと新しいクラスタが同時に稼働することはありませんので、両クラスタで同じポート番号を使用することができます。
 しかし実行中の古いクラスタを検査する時には、新旧で異なるポート番号でなければなりません。
     </para>
 
@@ -1268,7 +1268,7 @@ psql --username=postgres --file=script.sql postgres
 -->
 リンクモードを使用したいが、新しいクラスタを起動した時に古いクラスタを変更させたくない場合は、複製モードの使用を検討してください。
 もしそれが利用可能でないなら、古いクラスタのコピーを取得してからリンクモードでアップグレードを行ってください。
-有効な古いクラスタのコピーを取得するためには、サーバ稼動中に<command>rsync</command>を使用して古いクラスタの変動があるかもしれないコピーを作成し、古いサーバを停止させた後に、<command>rsync --checksum</command>を再度実行して一貫性を保つために何らかの変更をコピーに反映させます。
+有効な古いクラスタのコピーを取得するためには、サーバ稼働中に<command>rsync</command>を使用して古いクラスタの変動があるかもしれないコピーを作成し、古いサーバを停止させた後に、<command>rsync --checksum</command>を再度実行して一貫性を保つために何らかの変更をコピーに反映させます。
 （<command>rsync</command>はファイル更新時刻の粒度が1秒しかないので<option>--checksum</option>が必要です。）
 例えば<xref linkend="backup-lowlevel-base-backup"/>で説明した<filename>postmaster.pid</filename>など、一部のファイルを除外したいと考えるかもしれません。
 スナップショットやコピーは同時、もしくはデータベースサーバが停止しているときに作らなければなりませんが、ファイルシステムがファイルシステムのスナップショットやコピーオンライトファイルコピーをサポートしているのなら、それを古いクラスタとテーブル空間のバックアップをするのに使うことができます。