Re: BBU Cache vs. spindles

Bruce Momjian <bruce@momjian.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