Re: BBU Cache vs. spindles

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: BBU Cache vs. spindles
Дата
Msg-id 4CC04EA50200002500036C5E@gw.wicourts.gov
обсуждение исходный текст
Ответ на Re: BBU Cache vs. spindles  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: BBU Cache vs. spindles  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-performance
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

В списке pgsql-performance по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: BBU Cache vs. spindles
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: BBU Cache vs. spindles