Bruce Momjian <bruce@xxxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
