Reliability is an important property of any serious database system, and <productname>PostgreSQL</productname> does everything possible to guarantee reliable operation. One aspect of reliable operation is that all data recorded by a committed transaction should be stored in a nonvolatile area that is safe from power loss, operating system failure, and hardware failure (except failure of the nonvolatile area itself, of course). Successfully writing the data to the computer's permanent storage (disk drive or equivalent) ordinarily meets this requirement. In fact, even if a computer is fatally damaged, if the disk drives survive they can be moved to another computer with similar hardware and all committed transactions will remain intact. 信頼性は、すべての本格的なデータベースシステムで重要な特性です。 PostgreSQLは信頼できる操作を保証するためにできることは何でもします。 信頼できる操作の一面は、コミットされたトランザクションにより記録されたデータはすべて不揮発性の領域に格納され、電源断、オペレーティングシステムの障害、ハードウェアの障害（当然ですが、不揮発性の領域自体の障害は除きます。）があっても安全であるという点です。 通常、コンピュータの永続的格納領域（ディスク装置など）へのデータ書き込みの成功がこの条件を満たします。 実際、コンピュータに致命的な障害が発生したとしても、もしディスク装置が無事ならば、類似のハードウェアを持つ別のコンピュータに移すことができ、コミットされたトランザクションを元通りに復元できます。

While forcing data to the disk platters periodically might seem like a simple operation, it is not. Because disk drives are dramatically slower than main memory and CPUs, several layers of caching exist between the computer's main memory and the disk platters. First, there is the operating system's buffer cache, which caches frequently requested disk blocks and combines disk writes. Fortunately, all operating systems give applications a way to force writes from the buffer cache to disk, and <productname>PostgreSQL</productname> uses those features. (See the <xref linkend="guc-wal-sync-method"/> parameter to adjust how this is done.) データを周期的にディスクプラッタに書き出すことは簡単な操作に思われるかもしれませんが、そうではありません。 ディスク装置は主メモリ、CPU、コンピュータの主メモリとディスクプラッタの間にある各種のキャッシュ層と比べ非常に低速であるからです。 まず、オペレーティングシステムのバッファキャッシュが存在します。 これは頻繁にアクセス要求があるディスクブロックをキャッシュし、ディスクへの書き込みをまとめます。 好運にもすべてのオペレーティングシステムがバッファキャッシュをディスクに強制書き込みさせる方法をアプリケーションに提供しています。 PostgreSQLはこの機能を使用します。 （これを調整する方法についてはwal_sync_methodパラメータを参照してください。）

Next, there might be a cache in the disk drive controller; this is particularly common on <acronym>RAID</acronym> controller cards. Some of these caches are <firstterm>write-through</firstterm>, meaning writes are sent to the drive as soon as they arrive. Others are <firstterm>write-back</firstterm>, meaning data is sent to the drive at some later time. Such caches can be a reliability hazard because the memory in the disk controller cache is volatile, and will lose its contents in a power failure. Better controller cards have <firstterm>battery-backup units</firstterm> (<acronym>BBU</acronym>s), meaning the card has a battery that maintains power to the cache in case of system power loss. After power is restored the data will be written to the disk drives. 次に、ディスク装置のコントローラキャッシュが存在する可能性があります。 特に、RAIDコントローラカードでは、これは一般的です。 これらの中にはwrite-throughキャッシュがあり、つまり、データが届いた時に即座に書き込みがディスク装置に対して行なわれます。 他にはwrite-backキャッシュがあり、多少遅れて書き込みがディスク装置に対して行なわれます。 こうしたキャッシュでは、ディスクコントローラキャッシュが揮発性で、電源障害の際にその内容が失われてしまい、信頼性に関して致命的な問題になる可能性があります。 より優れたコントローラカードにはバッテリバックアップ付き装置(BBUs)があり、システムの電源が落ちた場合もキャッシュに電源を供給します。 後で電源が復旧した後に、データがディスク装置に書き出されます。

And finally, most disk drives have caches. Some are write-through while some are write-back, and the same concerns about data loss exist for write-back drive caches as for disk controller caches. Consumer-grade IDE and SATA drives are particularly likely to have write-back caches that will not survive a power failure. Many solid-state drives (SSD) also have volatile write-back caches. 最後に、ほとんどのディスク装置がキャッシュを持っています。一部はwrite-throughであり、一部はwrite-backです。 ディスクコントローラキャッシュの場合と同様にwrite-backのディスク装置キャッシュの場合にはデータが損失する恐れがあります。 一般消費者向けのIDEおよびSATA装置では、電源障害時にデータが残らないwrite-backキャッシュを使用している可能性がとりわけ高いです。 多くのソリッドステートドライブ(SSD)も同様に揮発性のwrite-backキャッシュを持っています。

These caches can typically be disabled; however, the method for doing this varies by operating system and drive type: これらのキャッシュは、大抵は無効にできます。しかしながらオペレーティングシステムやドライブの種類によってその方法は異なります。

Recent SATA drives (those following <acronym>ATAPI-6</acronym> or later) offer a drive cache flush command (<command>FLUSH CACHE EXT</command>), while SCSI drives have long supported a similar command <command>SYNCHRONIZE CACHE</command>. These commands are not directly accessible to <productname>PostgreSQL</productname>, but some file systems (e.g., <acronym>ZFS</acronym>, <acronym>ext4</acronym>) can use them to flush data to the platters on write-back-enabled drives. Unfortunately, such file systems behave suboptimally when combined with battery-backup unit (<acronym>BBU</acronym>) disk controllers. In such setups, the synchronize command forces all data from the controller cache to the disks, eliminating much of the benefit of the BBU. You can run the <xref linkend="pgtestfsync"/> program to see if you are affected. If you are affected, the performance benefits of the BBU can be regained by turning off write barriers in the file system or reconfiguring the disk controller, if that is an option. If write barriers are turned off, make sure the battery remains functional; a faulty battery can potentially lead to data loss. Hopefully file system and disk controller designers will eventually address this suboptimal behavior. 最近のSATAドライブ(ATAPI-6またはそれ以降)はドライブキャッシュの書き出しコマンド(FLUSH CACHE EXT)を提供している一方、SCSIドライブでは従来から類似のSYNCHRONIZE CACHEコマンドをサポートしていました。 これらのコマンドは、直接PostgreSQLに発行されませんが、いくつかのファイルシステム(例えばZFSやext4)では、それらをwrite-backが有効なドライブへデータを書き出すために使います。 不幸なことに、このようなwriteバリアを持つファイルシステムは、バッテリバックアップ付き装置(BBU)のディスクコントローラと組み合わせた際に、好ましい動作をしません。 このような処理の流れにおいて、同期コマンドはコントローラキャッシュにあるデータを全てディスクへ強制的に書き込みを行うため、BBUのメリットの大半を失わせています。 pg_test_fsyncプログラムを使うことで、あなたの環境が影響を受けるかどうかを確認できます。 もし影響を受けるようであれば、ファイルシステムのwriteバリアを無効にするか、(オプションがあれば)ディスクコントローラを再設定することで、BBUによる性能上の効果を再び得ることができるでしょう。 もしwriteバリアを無効にした場合は、バッテリが動作していることを確認しておきましょう。バッテリの欠陥はデータロスの可能性に繋がります。 ファイルシステムやディスクコントローラの設計者が、いずれはこの動作を修正してくれることが望まれます。

When the operating system sends a write request to the storage hardware, there is little it can do to make sure the data has arrived at a truly non-volatile storage area. Rather, it is the administrator's responsibility to make certain that all storage components ensure integrity for both data and file-system metadata. Avoid disk controllers that have non-battery-backed write caches. At the drive level, disable write-back caching if the drive cannot guarantee the data will be written before shutdown. If you use SSDs, be aware that many of these do not honor cache flush commands by default. You can test for reliable I/O subsystem behavior using <ulink url="https://brad.livejournal.com/2116715.html"><filename>diskchecker.pl</filename></ulink>. オペレーティングシステムが、ストレージハードウェアに書き込み要求を送信した時、データが不揮発性のストレージ領域に本当に届いたかどうかを確認することはほぼできません。 ですので、全てのストレージ構成品がデータとファイルシステムのメタデータの整合性を保証することをよく確認しておくことは、管理者の責任です。 バッテリバックアップされた書き込みキャッシュを持たないコントローラの使用は避けてください。 装置レベルでは、もし装置が停止前にデータが書き出されることを保証できないのであれば、write-backキャッシュを無効にしてください。 もしSSDを使っている場合、多くのドライブはデフォルトでキャッシュ書き出しコマンドを無視することに注意して下さい。 diskchecker.plを使うことで、I/Oサブシステムの動作の信頼性をテストすることができます。

Another risk of data loss is posed by the disk platter write operations themselves. Disk platters are divided into sectors, commonly 512 bytes each. Every physical read or write operation processes a whole sector. When a write request arrives at the drive, it might be for some multiple of 512 bytes (<productname>PostgreSQL</productname> typically writes 8192 bytes, or 16 sectors, at a time), and the process of writing could fail due to power loss at any time, meaning some of the 512-byte sectors were written while others were not. To guard against such failures, <productname>PostgreSQL</productname> periodically writes full page images to permanent WAL storage <emphasis>before</emphasis> modifying the actual page on disk. By doing this, during crash recovery <productname>PostgreSQL</productname> can restore partially-written pages from WAL. If you have file-system software that prevents partial page writes (e.g., ZFS), you can turn off this page imaging by turning off the <xref linkend="guc-full-page-writes"/> parameter. Battery-Backed Unit (BBU) disk controllers do not prevent partial page writes unless they guarantee that data is written to the BBU as full (8kB) pages. ディスクプラッタの書き込み操作自体によってもデータ損失が発生することがあります。 ディスクプラッタは、通常512バイトのセクタに分割されています。 物理的な読み込み操作、書き込み操作はすべて、セクタ全体を処理します。 書き込み要求がディスクに達した時、その要求は512バイトの倍数になるでしょう(PostgreSQLでは大抵一度に8192バイトすなわち16セクタを書き込みます)。そして電源断により、任意のタイミングで書き込み処理が失敗することがありえます。これは一部の512バイトのセクタに書き込みが行なわれたのに、残りのセクタには書き込みが行なわれていない状況を意味します。 こうした問題の対策として、PostgreSQLは、ディスク上の実際のページを変更する前に定期的にページ全体のイメージを永続的なWAL格納領域に書き出します。 これにより、PostgreSQLはクラッシュリカバリ時に部分的に書き出されたページをWALから復旧させることができます。 もし、部分的なページ書き込みを防止できるファイルシステムソフトウェア（例えばZFS）を使うのであれば、full_page_writesを無効にしてページイメージ作成を無効にすることができます。バッテリバックアップ付き（BBU）のディスクコントローラでは、フルページ（8kB）がBBUへ書き込まれることを保証できなければ、部分的なページ書き出しを防止できません。

<productname>PostgreSQL</productname> also protects against some kinds of data corruption on storage devices that may occur because of hardware errors or media failure over time, such as reading/writing garbage data. さらにPostgreSQLは、ハードウェアエラーや経時変化によるメディア障害により発生する、ごみデータを読み書きしてしまうようなストレージ装置内のある種のデータ破損を防ぎます。

<productname>PostgreSQL</productname> does not protect against correctable memory errors and it is assumed you will operate using RAM that uses industry standard Error Correcting Codes (ECC) or better protection. PostgreSQLは修復可能なメモリエラーに対して保護を行いません。業界標準の誤り検出訂正（Error Correcting Codes -ECC-）またはそれ以上の保護付きのRAM使用が想定されています。