When the <xref linkend="guc-hot-standby"/> parameter is set to true on a standby server, it will begin accepting connections once the recovery has brought the system to a consistent state. All such connections are strictly read-only; not even temporary tables may be written. スタンバイサーバでhot_standbyパラメータが真に設定されている場合、リカバリによりシステムが一貫性を持つようになった後接続を受け付け始めます。 こうした接続はすべて読み取り専用に限定されます。 一時テーブルであっても書き込むことはできません。

The data on the standby takes some time to arrive from the primary server so there will be a measurable delay between primary and standby. Running the same query nearly simultaneously on both primary and standby might therefore return differing results. We say that data on the standby is <firstterm>eventually consistent</firstterm> with the primary. Once the commit record for a transaction is replayed on the standby, the changes made by that transaction will be visible to any new snapshots taken on the standby. Snapshots may be taken at the start of each query or at the start of each transaction, depending on the current transaction isolation level. For more details, see <xref linkend="transaction-iso"/>. スタンバイ上のデータはプライマリサーバから届くまでに多少の時間がかかります。 このため、プライマリとスタンバイの間にはある程度の遅延があります。 したがって、同じ問い合わせをほとんど同時にプライマリとスタンバイに対して実行すると、異なる結果が返る可能性があります。 スタンバイ上のデータはプライマリに対して最後には一貫性を持つといいます。 あるトランザクションのコミットレコードがスタンバイ上で再生されると、そのトランザクションでなされた変更はスタンバイで獲得されるすべての新規スナップショットで可視になります。 現在のトランザクション分離レベルに応じて、スナップショットは各問い合わせの開始時または各トランザクションの開始時に獲得されます。 詳細については13.2を参照してください。

Transactions started during hot standby may issue the following commands: ホットスタンバイ中に開始されたトランザクションは以下のコマンドを発行することができます。

Transactions started during hot standby will never be assigned a transaction ID and cannot write to the system write-ahead log. Therefore, the following actions will produce error messages: ホットスタンバイ中に開始したトランザクションではトランザクションIDを割り当てられません。 また、システムのログ先行書き込みに書き出すことができません。 このため、以下の動作はエラーメッセージを生成します。

In normal operation, <quote>read-only</quote> transactions are allowed to use <command>LISTEN</command> and <command>NOTIFY</command>, so hot standby sessions operate under slightly tighter restrictions than ordinary read-only sessions. It is possible that some of these restrictions might be loosened in a future release. 通常の操作では、「読み取り専用」トランザクションにはLISTENとNOTIFYの使用が許可されています。 ホットスタンバイセッションの操作では、通常の読み取り専用セッションよりも少し厳しい制約を受けます。 将来のリリースではこの制約の一部が緩和されるかもしれません。

During hot standby, the parameter <varname>transaction_read_only</varname> is always true and may not be changed. But as long as no attempt is made to modify the database, connections during hot standby will act much like any other database connection. If failover or switchover occurs, the database will switch to normal processing mode. Sessions will remain connected while the server changes mode. Once hot standby finishes, it will be possible to initiate read-write transactions (even from a session begun during hot standby). ホットスタンバイ中は、transaction_read_onlyパラメータは常に真であり、変更することはできません。 しかし、データベースを変更するような試行がない限り、ホットスタンバイ中の接続は他のデータベース接続とほとんど同じように動作します。 もし、フェイルオーバーまたはスイッチオーバーが発生すると、データベースは通常処理モードに切り替わります。 サーバのモードが変わってもセッションは接続を保持します。 ホットスタンバイが完了すると、読み書き可能なトランザクションを（ホットスタンバイ中に始まったセッションからであっても）始められるようになります。

Users can determine whether hot standby is currently active for their session by issuing <command>SHOW in_hot_standby</command>. (In server versions before 14, the <varname>in_hot_standby</varname> parameter did not exist; a workable substitute method for older servers is <command>SHOW transaction_read_only</command>.) In addition, a set of functions (<xref linkend="functions-recovery-info-table"/>) allow users to access information about the standby server. These allow you to write programs that are aware of the current state of the database. These can be used to monitor the progress of recovery, or to allow you to write complex programs that restore the database to particular states. ユーザはSHOW in_hot_standbyを発行することで、そのセッションが読み取り専用かどうかを調べることができます。 （サーババージョンが14より前ではin_hot_standbyパラメータは存在しませんでした。古いバージョンでの可能な代替方法は、SHOW transaction_read_onlyです。） さらに、ユーザがスタンバイサーバに関する情報にアクセスできる関数群(表 9.92)があります。 これらによりデータベースの現状認識を行うプログラムを作成することができます。 これらを使用して、リカバリの進行状況を監視するために使用したり、データベースを特定の状態にリストアする複雑なプログラムを作成したりすることができます。

The primary and standby servers are in many ways loosely connected. Actions on the primary will have an effect on the standby. As a result, there is potential for negative interactions or conflicts between them. The easiest conflict to understand is performance: if a huge data load is taking place on the primary then this will generate a similar stream of WAL records on the standby, so standby queries may contend for system resources, such as I/O. プライマリサーバとスタンバイサーバは、多方面でゆるく結合しています。 プライマリサーバの動作はスタンバイサーバに影響します。 その結果、負の相互作用またはコンフリクトの可能性があります。 最も分かりやすいコンフリクトは性能です。 プライマリサーバで巨大なデータがロードされた場合、スタンバイサーバにおいて同様に巨大なWALレコードが生成されるので、スタンバイサーバにおける問い合わせは互いにI/Oなどのシステム資源を奪い合います。

There are also additional types of conflict that can occur with hot standby. These conflicts are <emphasis>hard conflicts</emphasis> in the sense that queries might need to be canceled and, in some cases, sessions disconnected to resolve them. The user is provided with several ways to handle these conflicts. Conflict cases include: ホットスタンバイで発生する可能性があるコンフリクトの種類には他にもあります。 これらのコンフリクトは、問い合わせをキャンセルしなければならない可能性があり、解消させるためにはセッションの接続を閉ざすことになる場合もあるため、致命的なコンフリクトです。 ユーザにはこうしたコンフリクトを扱うための複数の方法が提供されます。 コンフリクトする状況には以下があります。

On the primary server, these cases simply result in waiting; and the user might choose to cancel either of the conflicting actions. However, on the standby there is no choice: the WAL-logged action already occurred on the primary so the standby must not fail to apply it. Furthermore, allowing WAL application to wait indefinitely may be very undesirable, because the standby's state will become increasingly far behind the primary's. Therefore, a mechanism is provided to forcibly cancel standby queries that conflict with to-be-applied WAL records. プライマリサーバでは、こうした状況は単に待たされるだけです。 ユーザはコンフリクトする操作をキャンセルすることを選ぶことができます。 しかし、スタンバイ側には選択肢がありません。 WALに記録された操作はすでにプライマリで発生したものですので、スタンバイではその適用に失敗してはなりません。 さらに、適用したいWALを無制限に待機させることを許すことは、まったく望まない結果になってしまうかもしれません。 なぜなら、スタンバイの状態がプライマリの状態とだんだんとかけ離れてしまうからです。 したがって適用すべきWALレコードとコンフリクトするスタンバイの問い合わせを強制的に取り消す仕組みが用意されています。

An example of the problem situation is an administrator on the primary server running <command>DROP TABLE</command> on a table that is currently being queried on the standby server. Clearly the standby query cannot continue if the <command>DROP TABLE</command> is applied on the standby. If this situation occurred on the primary, the <command>DROP TABLE</command> would wait until the other query had finished. But when <command>DROP TABLE</command> is run on the primary, the primary doesn't have information about what queries are running on the standby, so it will not wait for any such standby queries. The WAL change records come through to the standby while the standby query is still running, causing a conflict. The standby server must either delay application of the WAL records (and everything after them, too) or else cancel the conflicting query so that the <command>DROP TABLE</command> can be applied. この問題の例として、スタンバイサーバで現在問い合わせ対象となっているテーブルをプライマリサーバでDROP TABLEを行う管理者を考えてみます。 スタンバイでDROP TABLEが適用されたら問い合わせを継続できないことは明確です。 プライマリ上でこうした状況が発生した場合は、他の問い合わせが終わるまでDROP TABLEは待機させられます。 しかし、DROP TABLEがプライマリで実行された時、プライマリ側でスタンバイで稼働する問い合わせに関する情報がありませんので、スタンバイ側のこうした問い合わせを待機させることはできません。 スタンバイ側で問い合わせが実行している時にWALの変更レコードがスタンバイに届けば、コンフリクトが発生します。 スタンバイサーバはWALレコードの適用を遅延させる（およびその後の適用すべても遅延させる）か、DROP TABLEを適用できるようにコンフリクトする問い合わせを取り消すかのいずれかを行わなければなりません。

When a conflicting query is short, it's typically desirable to allow it to complete by delaying WAL application for a little bit; but a long delay in WAL application is usually not desirable. So the cancel mechanism has parameters, <xref linkend="guc-max-standby-archive-delay"/> and <xref linkend="guc-max-standby-streaming-delay"/>, that define the maximum allowed delay in WAL application. Conflicting queries will be canceled once it has taken longer than the relevant delay setting to apply any newly-received WAL data. There are two parameters so that different delay values can be specified for the case of reading WAL data from an archive (i.e., initial recovery from a base backup or <quote>catching up</quote> a standby server that has fallen far behind) versus reading WAL data via streaming replication. コンフリクトする問い合わせが短ければ、適用したいWALを多少遅延させることで、問い合わせを完了させることが通常望まれます。 しかし、WALの適用が長く遅延することはたいていは望まれません。 したがって、取り消し機能はmax_standby_archive_delayとmax_standby_streaming_delayというパラメータを持ちます。 これらはWAL適用に許される遅延を定義するものです。 コンフリクトする問い合わせは、何らかの新しく受信したWALデータを適用するための各種遅延設定を超えたら取り消されます。 アーカイブからWALデータを読み取る場合（つまりベースバックアップからの初期リカバリや大きく遅延したスタンバイサーバの「追従」）とストリーミングレプリケーションとで異なる遅延値を指定することができるように2つのパラメータが存在します。

In a standby server that exists primarily for high availability, it's best to set the delay parameters relatively short, so that the server cannot fall far behind the primary due to delays caused by standby queries. However, if the standby server is meant for executing long-running queries, then a high or even infinite delay value may be preferable. Keep in mind however that a long-running query could cause other sessions on the standby server to not see recent changes on the primary, if it delays application of WAL records. 主に高可用性のために存在するスタンバイサーバでは、スタンバイ側の問い合わせによって発生する遅延のためにプライマリと大きく遅延が発生することがないように、遅延パラメータを相対的に短く設定することが最善です。 しかし、スタンバイサーバが長時間かかる問い合わせを実行するためのものであれば、長い遅延もしくは制限を設けないことが好まれるかもしれません。 しかし、長時間かかる問い合わせがWALレコードの適用を遅延させてしまう場合、スタンバイサーバ上の他のセッションがプライマリにおける最近の変更を参照することができなくなることは覚えておいてください。

Once the delay specified by <varname>max_standby_archive_delay</varname> or <varname>max_standby_streaming_delay</varname> has been exceeded, conflicting queries will be canceled. This usually results just in a cancellation error, although in the case of replaying a <command>DROP DATABASE</command> the entire conflicting session will be terminated. Also, if the conflict is over a lock held by an idle transaction, the conflicting session is terminated (this behavior might change in the future). max_standby_archive_delayまたはmax_standby_streaming_delayで指定した遅延を超えると、コンフリクトする問い合わせは取り消されます。 通常これは単なる取り消しエラーという結果となりますが、DROP DATABASEを再生する場合では、コンフリクトするセッション全体が終了します。 また、コンフリクトが待機中のトランザクションで保持されるロックについてのものであれば、そのコンフリクトするセッションが終了します（この動作は将来変更されるかもしれません）。

Canceled queries may be retried immediately (after beginning a new transaction, of course). Since query cancellation depends on the nature of the WAL records being replayed, a query that was canceled may well succeed if it is executed again. ユーザは取り消された問い合わせをすぐに再試行するかもしれません（もちろん新規のトランザクション開始後に）。 問い合わせの取り消しは、再生されるWALレコードの性質に依存するので、取り消された問い合わせが再度実行された場合には正常に動作するかもしれません。

Keep in mind that the delay parameters are compared to the elapsed time since the WAL data was received by the standby server. Thus, the grace period allowed to any one query on the standby is never more than the delay parameter, and could be considerably less if the standby has already fallen behind as a result of waiting for previous queries to complete, or as a result of being unable to keep up with a heavy update load. 遅延パラメータはスタンバイサーバでWALデータを受信してからの経過時間と比べられることに注意してください。 したがって、スタンバイ上で任意の問い合わせに許される猶予期間は、この遅延パラメータよりも大きくなることは決してありません。 これまでの問い合わせを完了させるために待機した結果、あるいは、大量の更新負荷に追従することができなくなった結果、スタンバイがすでに遅延している場合は相当小さくなります。

The most common reason for conflict between standby queries and WAL replay is <quote>early cleanup</quote>. Normally, <productname>PostgreSQL</productname> allows cleanup of old row versions when there are no transactions that need to see them to ensure correct visibility of data according to MVCC rules. However, this rule can only be applied for transactions executing on the primary. So it is possible that cleanup on the primary will remove row versions that are still visible to a transaction on the standby. スタンバイ側の問い合わせとWAL再生の間でもっともよくあるコンフリクト理由は「早すぎるクリーンアップ」です。 通常PostgreSQLはMVCC規則にしたがって正確なデータの可視性を確実にするために、古い行バージョンを参照するトランザクションが存在しない場合それらをクリーンアップすることが許されています。 しかし、この規則はプライマリ上で実行するトランザクションのみに適用させることができます。 したがって、スタンバイ上のトランザクションでまだ可視である行バージョンを、プライマリ上のクリーンアップ処理が削除してしまう可能性があります。

Row version cleanup isn't the only potential cause of conflicts with standby queries. All index-only scans (including those that run on standbys) must use an <acronym>MVCC</acronym> snapshot that <quote>agrees</quote> with the visibility map. Conflicts are therefore required whenever <command>VACUUM</command> <link linkend="vacuum-for-visibility-map">sets a page as all-visible in the visibility map</link> containing one or more rows <emphasis>not</emphasis> visible to all standby queries. So even running <command>VACUUM</command> against a table with no updated or deleted rows requiring cleanup might lead to conflicts. スタンバイ問い合わせとの競合の潜在的な原因は、行バージョンのクリーンアップだけではありません。 すべてのインデックスオンリースキャン（スタンバイで実行されるものも含む）は、可視性マップに「同意する」MVCCスナップショットを使用しなければなりません。 したがって、VACUUMが、すべてのスタンバイの問い合わせに対して1行以上の非可視行を含み、一つのページがすべて可視であるような可視性マップを設定する時には、必ず競合が必要になります。 ですから、クリーンアップが必要で、更新や削除された行を含まないテーブルに対してVACUUMを実行しても競合が発生する可能性があります。

Users should be clear that tables that are regularly and heavily updated on the primary server will quickly cause cancellation of longer running queries on the standby. In such cases the setting of a finite value for <varname>max_standby_archive_delay</varname> or <varname>max_standby_streaming_delay</varname> can be considered similar to setting <varname>statement_timeout</varname>. プライマリサーバにおいて規則的かつ頻繁に更新されるテーブルは、スタンバイサーバにおける問い合わせの取り消しの原因になりやすいことを利用者は理解するべきです。 そのような場合、max_standby_archive_delayまたはmax_standby_streaming_delayの設定値はstatement_timeoutの設定と同様に考えることができます。

Remedial possibilities exist if the number of standby-query cancellations is found to be unacceptable. The first option is to set the parameter <varname>hot_standby_feedback</varname>, which prevents <command>VACUUM</command> from removing recently-dead rows and so cleanup conflicts do not occur. If you do this, you should note that this will delay cleanup of dead rows on the primary, which may result in undesirable table bloat. However, the cleanup situation will be no worse than if the standby queries were running directly on the primary server, and you are still getting the benefit of off-loading execution onto the standby. If standby servers connect and disconnect frequently, you might want to make adjustments to handle the period when <varname>hot_standby_feedback</varname> feedback is not being provided. For example, consider increasing <varname>max_standby_archive_delay</varname> so that queries are not rapidly canceled by conflicts in WAL archive files during disconnected periods. You should also consider increasing <varname>max_standby_streaming_delay</varname> to avoid rapid cancellations by newly-arrived streaming WAL entries after reconnection. スタンバイにおける問い合わせの中断が受け入れがたいほど多い場合、この問題を改善する方法が用意されています。 １つ目の選択肢は、hot_standby_feedbackパラメータを設定することです。 これはVACUUMによる最近不要になった行の削除を防止しますので、クリーンアップによるコンフリクトが発生しません。 これを行う場合、プライマリで不要になった行のクリーンアップが遅延することに注意が必要です。望まないテーブルの膨張が発生してしまうかもしれません。 しかし、スタンバイ側で行うべき問い合わせをプライマリサーバ上で直接実行することと比べ、こうしたクリーンアップに関する問題を優先する価値はありません。 また、スタンバイに実行負荷を分散できるという利点があります。 スタンバイサーバが接続、切断を頻繁に繰り返す場合、hot_standby_feedbackによるフィードバックが提供されていなければ、その値を調整したいと思うでしょう。 例えば、max_standby_archive_delayが増大し、切断している期間WALアーカイブのコンフリクト発生による問い合わせの中断が速やかに行われないことを考えてみてください。また、再接続後に速やかに問い合わせが中断されることを避けるためにmax_standby_streaming_delayを大きくすることを考えてみてください。

The number of query cancels and the reason for them can be viewed using the <structname>pg_stat_database_conflicts</structname> system view on the standby server. The <structname>pg_stat_database</structname> system view also contains summary information. 問い合わせキャンセルの個数とその原因はスタンバイサーバ上のpg_stat_database_conflictsシステムビューを用いて参照することができます。 またpg_stat_databaseシステムビューには要約された情報が含まれます。

Users can control whether a log message is produced when WAL replay is waiting longer than <varname>deadlock_timeout</varname> for conflicts. This is controlled by the <xref linkend="guc-log-recovery-conflict-waits"/> parameter. コンフリクトのためにWAL再生がdeadlock_timeoutより長くかかる場合にログメッセージを出力するかどうかをユーザは制御できます。 log_recovery_conflict_waitsパラメータで制御します。

If <varname>hot_standby</varname> is <literal>on</literal> in <filename>postgresql.conf</filename> (the default value) and there is a <link linkend="file-standby-signal"><filename>standby.signal</filename></link><indexterm><primary>standby.signal</primary><secondary>for hot standby</secondary></indexterm> file present, the server will run in hot standby mode. However, it may take some time for hot standby connections to be allowed, because the server will not accept connections until it has completed sufficient recovery to provide a consistent state against which queries can run. During this period, clients that attempt to connect will be refused with an error message. To confirm the server has come up, either loop trying to connect from the application, or look for these messages in the server logs: postgresql.confにおいてhot_standbyがonで（これはデフォルトです）、かつstandby.signalが存在すれば、サーバはホットスタンバイモードで稼働します。 しかし、サーバはまず問い合わせが実行できる程度の一貫性を持つ状態を提供するために十分なリカバリを完了させなければなりませんので、ホットスタンバイでの接続が有効になるまでに多少の時間がかかるかもしれません。 サーバの準備ができたことを確認するために、アプリケーションで接続試行を繰り返すか、サーバログに以下のメッセージがあるかどうかを確認します。

LOG:  entering standby mode


... then some time later ...

... 多少時間が経過して ...

LOG:  consistent recovery state reached
LOG:  database system is ready to accept read-only connections

Consistency information is recorded once per checkpoint on the primary. It is not possible to enable hot standby when reading WAL written during a period when <varname>wal_level</varname> was not set to <literal>replica</literal> or <literal>logical</literal> on the primary. Reaching a consistent state can also be delayed in the presence of both of these conditions: 一貫性に関する情報はプライマリでチェックポイント毎に一回記録されます。 プライマリでwal_levelがreplicaもしくはlogicalに設定されていなかった期間に書き込まれたWALを読み取っている間は、ホットスタンバイを有効にすることはできません。 また、一貫性のある状態への到達は、以下の両方が存在する間遅延することがあります。

If you are running file-based log shipping ("warm standby"), you might need to wait until the next WAL file arrives, which could be as long as the <varname>archive_timeout</varname> setting on the primary. ファイルベースのログシッピング(「ウォームスタンバイ」)を実行しているのであれば、次のWALファイルが届く、長くともプライマリのarchive_timeout設定まで待機しなければなりません。

The settings of some parameters determine the size of shared memory for tracking transaction IDs, locks, and prepared transactions. These shared memory structures must be no smaller on a standby than on the primary in order to ensure that the standby does not run out of shared memory during recovery. For example, if the primary had used a prepared transaction but the standby had not allocated any shared memory for tracking prepared transactions, then recovery could not continue until the standby's configuration is changed. The parameters affected are: いくつかのパラメータの設定により、トランザクションID、ロック、準備されたトランザクションを追跡するための共有メモリのサイズが決まります。 リカバリ中に共有メモリを使い尽くすことがないことを確実にするために、スタンバイサーバにおける設定値は、プライマリサーバにおける設定値以上でなければなりません。 たとえばプライマリが準備されたトランザクションを実行していてスタンバイが準備されたトランザクションを追跡するための共有メモリを獲得していなければ、スタンバイは設定が変更されるまではリカバリを続けることができません。 影響があるパラメータは以下です。

The easiest way to ensure this does not become a problem is to have these parameters set on the standbys to values equal to or greater than on the primary. Therefore, if you want to increase these values, you should do so on all standby servers first, before applying the changes to the primary server. Conversely, if you want to decrease these values, you should do so on the primary server first, before applying the changes to all standby servers. Keep in mind that when a standby is promoted, it becomes the new reference for the required parameter settings for the standbys that follow it. Therefore, to avoid this becoming a problem during a switchover or failover, it is recommended to keep these settings the same on all standby servers. これが問題にならないようにする確実な方法は、スタンバイにおけるこれらのパラメータの値をプライマリでの値以上にすることです。 ですから、これらの値を増やしたいなら、プライマリで設定を変更する前に、まずスタンバイで設定変更するべきです。 逆にこれらの値を減らしたいなら、スタンバイで設定を変更する前に、まずプライマリで設定変更するべきです。 スタンバイが昇格したときは、それが追従するスタンバイにとって必要なパラメータ設定の新しい基準になるということを覚えておいてください。 ですから、スイッチオーバーやフェイルオーバー中にこれが問題にならないようにするために、これらの設定値をすべてのスタンバイで同じにしておくことをお勧めします。

The WAL tracks changes to these parameters on the primary. If a hot standby processes WAL that indicates that the current value on the primary is higher than its own value, it will log a warning and pause recovery, for example: プライマリでWALはこれらのパラメータの変更を追跡します。 ホットスタンバイが現在のプライマリの値がスタンバイの値よりも大きいことを示すWALを処理すると、警告をログし、リカバリを中断します。 例を示します。

WARNING:  hot standby is not possible because of insufficient parameter settings
DETAIL:  max_connections = 80 is a lower setting than on the primary server, where its value was 100.
LOG:  recovery has paused
DETAIL:  If recovery is unpaused, the server will shut down.
HINT:  You can then restart the server after making the necessary configuration changes.

At that point, the settings on the standby need to be updated and the instance restarted before recovery can continue. If the standby is not a hot standby, then when it encounters the incompatible parameter change, it will shut down immediately without pausing, since there is then no value in keeping it up. この時点で、スタンバイの設定を変更し、リカバリを継続するためにインスタンスを再起動する必要があります。 スタンバイがホットスタンバイでない場合は、整合性のないパラメータの変更があると、休止することなく直ちにシャットダウンします。起動し続ける意味がないからです。

It is important that the administrator select appropriate settings for <xref linkend="guc-max-standby-archive-delay"/> and <xref linkend="guc-max-standby-streaming-delay"/>. The best choices vary depending on business priorities. For example if the server is primarily tasked as a High Availability server, then you will want low delay settings, perhaps even zero, though that is a very aggressive setting. If the standby server is tasked as an additional server for decision support queries then it might be acceptable to set the maximum delay values to many hours, or even -1 which means wait forever for queries to complete. max_standby_archive_delayおよびmax_standby_streaming_delayの値が適切であるように管理者が選択することが重要です。 最善の選択は業務上の優先順位によって変化します。 例えば、サーバが主に高可用性を目的としたサーバとして作業するものであれば、短い遅延を設定したいでしょう。 非常に積極的な設定ですが、ゼロにしたいかもしれません。 スタンバイサーバが意思決定支援のための問い合わせ用の追加サーバとして作業するものであれば、数時間程度の最大の遅延値の設定、あるいは問い合わせの完了を永遠に待つことを意味する-1という設定でさえ、許容範囲であるかもしれません。

Transaction status "hint bits" written on the primary are not WAL-logged, so data on the standby will likely re-write the hints again on the standby. Thus, the standby server will still perform disk writes even though all users are read-only; no changes occur to the data values themselves. Users will still write large sort temporary files and re-generate relcache info files, so no part of the database is truly read-only during hot standby mode. Note also that writes to remote databases using <application>dblink</application> module, and other operations outside the database using PL functions will still be possible, even though the transaction is read-only locally. プライマリ側で「ヒントビット」として書き出されたトランザクション状態はWALに記録されません。 このためスタンバイ側のデータはスタンバイ側でヒントを再度書き出すことになります。 ユーザは大規模なソート用の一時ファイルを書き出し、relcache情報ファイルを再作成します。 したがって、ホットスタンバイモードではデータベースのすべてが本当に読み取り専用ではありません。 また、ローカルでは読み取り専用のトランザクションであってもdblinkモジュールを使用したリモートデータベースへの書き出しや、その他のPL関数を使用したデータベース外部への操作が可能であることに注意してください。

The following types of administration commands are not accepted during recovery mode: リカバリモードの間、下記の管理者用コマンドは受理されません。

Again, note that some of these commands are actually allowed during "read only" mode transactions on the primary. 繰り返しますが、これらのコマンドの一部は、プライマリサーバにおける「読み取り専用」モードのトランザクションで実際に許可されていることに注意してください。

As a result, you cannot create additional indexes that exist solely on the standby, nor statistics that exist solely on the standby. If these administration commands are needed, they should be executed on the primary, and eventually those changes will propagate to the standby. その結果、スタンバイ側にのみ存在する追加のインデックスやスタンバイ側にのみ存在する統計情報を作成することはできません。 これらの管理者用コマンドが必要な場合、プライマリ側で実行しなければなりません。 最終的にこの変更はスタンバイ側に伝播します。

<function>pg_cancel_backend()</function> and <function>pg_terminate_backend()</function> will work on user backends, but not the startup process, which performs recovery. <structname>pg_stat_activity</structname> does not show recovering transactions as active. As a result, <structname>pg_prepared_xacts</structname> is always empty during recovery. If you wish to resolve in-doubt prepared transactions, view <literal>pg_prepared_xacts</literal> on the primary and issue commands to resolve transactions there or resolve them after the end of recovery. pg_cancel_backend()とpg_terminate_backend()はユーザを扱うバックエンドでは実行できますが、リカバリを実行する起動プロセスでは実行できません。 pg_stat_activityはリカバリ中のトランザクションをアクティブとして表示しません。 その結果、リカバリの間pg_prepared_xactsは常に空となります。 調査が必要な準備されたトランザクションがある場合は、プライマリサーバにおいてpg_prepared_xactsを表示し、その場でトランザクションを解決するか、リカバリが終わるのを待ってからトランザクションを解決します。

<structname>pg_locks</structname> will show locks held by backends, as normal. <structname>pg_locks</structname> also shows a virtual transaction managed by the startup process that owns all <literal>AccessExclusiveLocks</literal> held by transactions being replayed by recovery. Note that the startup process does not acquire locks to make database changes, and thus locks other than <literal>AccessExclusiveLocks</literal> do not show in <structname>pg_locks</structname> for the Startup process; they are just presumed to exist. pg_locksは通常通りバックエンドで保持されるロックを示します。 pg_locksはまた、リカバリによって再生されているトランザクションで保持されるAccessExclusiveLocksのすべてを所有する、起動プロセスで管理される仮想トランザクションも表示します。 起動プロセスはデータベースの変更を行うためのロックを獲得しません。 このため起動プロセスにおいてAccessExclusiveLocks以外のロックはpg_locksでは表示されません。 これらは存在することを想定されているだけです。

The <productname>Nagios</productname> plugin <productname>check_pgsql</productname> will work, because the simple information it checks for exists. The <productname>check_postgres</productname> monitoring script will also work, though some reported values could give different or confusing results. For example, last vacuum time will not be maintained, since no vacuum occurs on the standby. Vacuums running on the primary do still send their changes to the standby. 存在を検知する情報が単純なので、Nagiosプラグインcheck_pgsqlは稼働します。 一部の報告値が異なった、混乱を招く結果となりますが、check_postgresの監視スクリプトも動作します。 たとえば、スタンバイではバキュームが発生しないため、最終バキューム時刻は維持されません。 それでも、プライマリで行われるバキュームはその変更をスタンバイに送信します。

WAL file control commands will not work during recovery, e.g., <function>pg_backup_start</function>, <function>pg_switch_wal</function> etc. リカバリの間WALの制御コマンドは稼働しません。 例えば、pg_backup_startやpg_switch_walなどです。

Dynamically loadable modules work, including <structname>pg_stat_statements</structname>. pg_stat_statementsも含み、動的に読み込み可能なモジュールは稼働します。

Advisory locks work normally in recovery, including deadlock detection. Note that advisory locks are never WAL logged, so it is impossible for an advisory lock on either the primary or the standby to conflict with WAL replay. Nor is it possible to acquire an advisory lock on the primary 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の再実行においてコンフリクトが起こらないことに注意してください。 プライマリサーバでアドバイザリロックを取得して、スタンバイサーバで同様のアドバイザリロックを掛けることはできません。 アドバイザリロックは取得したサーバだけに関係するものです。

Trigger-based replication systems such as <productname>Slony</productname>, <productname>Londiste</productname> and <productname>Bucardo</productname> won't run on the standby at all, though they will run happily on the primary server as long as the changes are not sent to standby servers to be applied. WAL replay is not trigger-based so you cannot relay from the standby to any system that requires additional database writes or relies on the use of triggers. SlonyやLondisteやBucardoのようにトリガに基づいたレプリケーションシステムは、スタンバイサーバで全く稼働しません。 しかし、それによる変更がスタンバイサーバに送られるまでは、プライマリサーバにおいて問題なく稼働します。 WALの再実行はトリガに基づいたものではありません。 したがって、データベースへの付加的な書き込みを必要とするか、トリガの使用に依存するものを、スタンバイサーバを中継して他のシステムへ送ることはできません。

New OIDs cannot be assigned, though some <acronym>UUID</acronym> generators may still work as long as they do not rely on writing new status to the database. 一部のUUIDジェネレータは、データベースに新しい状態を書き出すことに依存していない限り動作可能ですが、新しいOIDを割り当てることはできません。

Currently, temporary table creation is not allowed during read-only transactions, so in some cases existing scripts will not run correctly. This restriction might be relaxed in a later release. This is both an SQL standard compliance issue and a technical issue. 現時点では、読み取り専用のトランザクションでは一時テーブルの作成は許されません。 このため既存のスクリプトが正しく動作しない場合があります。 この制限は将来のリリースで緩和されるかもしれません。 これは、標準SQLとの互換性の問題でもあり、技術的な問題でもあります。

<command>DROP TABLESPACE</command> can only succeed if the tablespace is empty. Some standby users may be actively using the tablespace via their <varname>temp_tablespaces</varname> parameter. If there are temporary files in the tablespace, all active queries are canceled to ensure that temporary files are removed, so the tablespace can be removed and WAL replay can continue. テーブル空間が空の場合だけ、DROP TABLESPACEが成功します。 一部のスタンバイ側のユーザはtemp_tablespacesパラメータを介してテーブル空間を活発に使用しているかもしれません。 テーブル空間に一時ファイルが存在する場合、一時ファイルを確実に削除するためすべての問い合わせが取り消されます。 このため、WAL再生を続けながらテーブル空間を削除することができます。

Running <command>DROP DATABASE</command> or <command>ALTER DATABASE ... SET TABLESPACE</command> on the primary will generate a WAL entry that will cause all users connected to that database on the standby to be forcibly disconnected. This action occurs immediately, whatever the setting of <varname>max_standby_streaming_delay</varname>. Note that <command>ALTER DATABASE ... RENAME</command> does not disconnect users, which in most cases will go unnoticed, though might in some cases cause a program confusion if it depends in some way upon database name. プライマリサーバにおけるDROP DATABASEまたはALTER DATABASE ... SET TABLESPACEの実行により、スタンバイサーバのデータベースに接続するすべてのユーザを強制的に接続を切断させることになるWALエントリを生成します。 これはmax_standby_streaming_delayの設定にかかわらず、直ちに起こります。 ALTER DATABASE ... RENAMEはユーザを切断しないので大部分の場合は気がつきませんが、プログラムがデータベースの名称に依存するときは混乱の原因となることに注意してください。

In normal (non-recovery) mode, if you issue <command>DROP USER</command> or <command>DROP ROLE</command> for a role with login capability while that user is still connected then nothing happens to the connected user &mdash; they remain connected. The user cannot reconnect however. This behavior applies in recovery also, so a <command>DROP USER</command> on the primary does not disconnect that user on the standby. 通常の(リカバリ以外の)モードで、ログイン権限を持つロールが接続している間にそのロールにDROP USERまたはDROP ROLEを発行した場合、接続中のユーザには何も起こらず、接続し続けます。 しかし、そのユーザは再接続できません。 この振舞いはリカバリモードでも適用されます。 このためプライマリ側でDROP USERされたとしても、スタンバイ側のユーザの接続は切断されません。

The cumulative statistics system is active during recovery. All scans, reads, blocks, index usage, etc., will be recorded normally on the standby. However, WAL replay will not increment relation and database specific counters. I.e. replay will not increment pg_stat_all_tables columns (like n_tup_ins), nor will reads or writes performed by the startup process be tracked in the pg_statio views, nor will associated pg_stat_database columns be incremented. リカバリの間も累積統計システムはアクティブになります。 すべてのスキャン、読み取り、ブロック、インデックスの使用などは、スタンバイサーバにおいて正常に記録されます。 しかし、WAL再生はリレーションやデータベース固有のカウンタを増加させません。 つまり、再生はpg_stat_all_tables列(n_tup_insなど)を増加させませんし、起動プロセスによって実行された読み取りや書き込みもpg_statioビューで追跡されませんし、関連するpg_stat_database列も増加されません。

Autovacuum is not active during recovery. It will start normally at the end of recovery. リカバリの間は自動バキュームは稼働しません。 リカバリが終わると正常に起動します。

The checkpointer process and the background writer process are active during recovery. The checkpointer process will perform restartpoints (similar to checkpoints on the primary) and the background writer process will perform normal block cleaning activities. This can include updates of the hint bit information stored on the standby server. The <command>CHECKPOINT</command> command is accepted during recovery, though it performs a restartpoint rather than a new checkpoint. リカバリの間、チェックポイントプロセスとバックグラウンドライタプロセスは稼働しています。 チェックポイントプロセスは（プライマリサーバにおけるチェックポイントに類似した）リスタートポイントを設定し、通常のブロック消去を行います。 これはスタンバイサーバに保存されるヒントビット情報の更新を含むことができます。 リカバリの間CHECKPOINTコマンドは受理されますが、新規のチェックポイントではなくてリスタートポイントが設定されます。

Various parameters have been mentioned above in <xref linkend="hot-standby-conflict"/> and <xref linkend="hot-standby-admin"/>. 種々のパラメータが上記27.4.2および27.4.3で述べられています。

On the primary, the <xref linkend="guc-wal-level"/> parameter can be used. <xref linkend="guc-max-standby-archive-delay"/> and <xref linkend="guc-max-standby-streaming-delay"/> have no effect if set on the primary. プライマリサーバでは、wal_levelのパラメータを使用できます。 プライマリサーバにmax_standby_archive_delayおよびmax_standby_streaming_delayを設定しても無効です。

On the standby, parameters <xref linkend="guc-hot-standby"/>, <xref linkend="guc-max-standby-archive-delay"/> and <xref linkend="guc-max-standby-streaming-delay"/> can be used. スタンバイでは、パラメータhot_standby、max_standby_archive_delay、max_standby_streaming_delayを使用できます。

There are several limitations of hot standby. These can and probably will be fixed in future releases: ホットスタンバイには幾つかの制限があります。 将来のリリースでは改善されると思われます。