Re: [SPAM] Re: WAL directory size calculation

Поиск
Список
Период
Сортировка
От Francisco Olarte
Тема Re: [SPAM] Re: WAL directory size calculation
Дата
Msg-id CA+bJJbwss0MYJgCOneOmPMxGoap16CkF1TFdPaWv4_W6frDwiQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [SPAM] Re: WAL directory size calculation  (Moreno Andreo <moreno.andreo@evolu-s.it>)
Ответы Re: [SPAM] Re: [SPAM] Re: WAL directory size calculation  (Moreno Andreo <moreno.andreo@evolu-s.it>)
Список pgsql-general
Hi:

On Fri, Jul 29, 2016 at 10:35 AM, Moreno Andreo
<moreno.andreo@evolu-s.it> wrote:
> After Andreas post and thinking about it a while, I went to the decision
> that it's better not to use RAM but another persistent disk, because there
> can be an instant between when a WAL is written and it's fsync'ed, and if a
> failure happens in this instant the amount of data not fsync'ed is lost. Am
> I right?

With the usual configuration, fsync on, etc.. what postgres does is to
write and sync THE WAL before commit, but it does not sync the table
pages. Should anything bad (tm) happen it can replay the synced wal to
recover. If you use a ram disk for WAL and have a large enough ram
cache you can lose a lot of data, not just from the last sync. At the
worst point you could start a transaction, create a database, fill it
and commit and have everything in the ram-wal and the hd cache, then
crash and have nothing on reboot.

Francisco Olarte.


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

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: [SPAM] Re: WAL directory size calculation
Следующее
От: Keith Fiske
Дата:
Сообщение: Re: Using timestamp(tz) in C functions