Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> If the write fails to the controller, the page is not flushed and
> PG does not continue. If the write fails, the fsync never
> happens, and hence PG stops.
PG stops? This case at issue is when the OS crashes or the plug is
pulled in the middle of writing a page. I don't think PG will
normally have the option of a graceful stop after that. To quote
the Fine Manual:
http://www.postgresql.org/docs/current/interactive/runtime-config-wal.html#GUC-FULL-PAGE-WRITES
| a page write that is in process during an operating system crash
| might be only partially completed, leading to an on-disk page that
| contains a mix of old and new data. The row-level change data
| normally stored in WAL will not be enough to completely restore
| such a page during post-crash recovery. Storing the full page
| image guarantees that the page can be correctly restored
Like I said, the only difference between the page being written to
platters and to a BBU cache that I can see is the average size of
the window of time in which you're vulnerable, not whether there is
a window. I don't think you've really addressed that concern.
-Kevin