From: | Francisco Olarte <folarte(at)peoplecall(dot)com> |
---|---|
To: | Moreno Andreo <moreno(dot)andreo(at)evolu-s(dot)it> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: [SPAM] Re: WAL directory size calculation |
Date: | 2016-07-29 15:26:55 |
Message-ID: | CA+bJJbwss0MYJgCOneOmPMxGoap16CkF1TFdPaWv4_W6frDwiQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi:
On Fri, Jul 29, 2016 at 10:35 AM, Moreno Andreo
<moreno(dot)andreo(at)evolu-s(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Keith Fiske | 2016-07-29 15:27:16 | Re: Using timestamp(tz) in C functions |
Previous Message | David G. Johnston | 2016-07-29 13:30:17 | Re: [SPAM] Re: WAL directory size calculation |