Kevin Grittner wrote: > 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: If the OS crashes during a write or fsync, we have not committed the transaction. > > 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. I assume we send a full 8k to the controller, and a failure during that write is not registered as a write. A disk drive is modifying permanent storage so there is always the possibility of that failing. I assume the BBU just rewrites that after startup. -- Bruce Momjian <bruce@xxxxxxxxxx> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
