Kevin Grittner wrote:
> 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:
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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
