Re: [SPAM] Re: WAL directory size calculation - Mailing list pgsql-general

From Moreno Andreo
Subject Re: [SPAM] Re: WAL directory size calculation
Date
Msg-id 5f43e1cd-9348-64bc-ff0c-1906db671277@evolu-s.it
Whole thread Raw
In response to Re: WAL directory size calculation  (Francisco Olarte <folarte@peoplecall.com>)
Responses Re: [SPAM] Re: WAL directory size calculation
Re: [SPAM] Re: WAL directory size calculation
List pgsql-general
Il 28/07/2016 20:45, Francisco Olarte ha scritto:
> On Thu, Jul 28, 2016 at 3:25 PM, Moreno Andreo <moreno.andreo@evolu-s.it> wrote:
>> Obviously ramdisk will be times faster disk, but having a, say, 512 GB
>> ramdisk will be a little too expensive :-)
> Besides defeating the purpose of WAL, if you are going to use non
> persistent storage for WAL you could as well use minimal level,
> fsync=off and friends.
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?
>
>> Aside of this, I'm having 350 DBs that sum up a bit more than 1 TB, and plan
>> to use wal_level=archive because I plan to have a backup server with barman.
> Is this why you plan using RAM for WAL ( assuming fast copies to the
> archive and relying on it for recovery ) ?
Yes, but having to deal with the risk of having loss of data, I think
I'll go on a bigger persistent disk, have bigger checkpoint intervals
and end up having a longer rescue time, but the main thing is *no data loss*
>
> Francisco Olarte.
>
>
Thanks

Moreno.




pgsql-general by date:

Previous
From: Achilleas Mantzios
Date:
Subject: Re: Uber migrated from Postgres to MySQL
Next
From: John R Pierce
Date:
Subject: Re: [SPAM] Re: WAL directory size calculation