Re: Allow wal_keep_segments to keep all segments - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Allow wal_keep_segments to keep all segments
Date
Msg-id 1275539743.21465.2831.camel@ebony
Whole thread Raw
In response to Re: Allow wal_keep_segments to keep all segments  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Allow wal_keep_segments to keep all segments
List pgsql-hackers
On Wed, 2010-06-02 at 20:28 -0400, Bruce Momjian wrote:
> Simon Riggs wrote:
> > On Wed, 2010-06-02 at 15:20 -0400, Bruce Momjian wrote:
> > 
> > > The attached patch allows wal_keep_segments = -1 to keep all segements; 
> > > this is particularly useful for taking a base backup, where you need all
> > > the WAL files during startup of the standby.  I have documented this
> > > usage in the patch as well.
> > > 
> > > I am thinking of applying this after 9.0 beta2 if there is no objection.
> > 
> > It's not clear to me why "keep all files until server breaks" is a good
> > setting. Surely you would set this parameter to the size of your disk.
> > Why allow it to go higher?
> 
> Well, the -1 allows them to set it temporarily without having to compute
> their free disk space.  Frankly, because the disk space varies, it is
> impossible to know exactly how large the disk is at the time it would
> fill up.
> 
> I think the normal computation would be:
> 
>     1) How long is my file system backup and restore to standby
>        going to take
>     2) How often do I generate a 16MB WAL file
> 
> You would do some computation to figure that out, then maybe multiply it
> by 10x and set that for wal_keep_segments.  I figured allowing a simple
> -1 would be easier.

I think its much easier to find out your free disk space than it is to
calculate how much WAL might be generated during backup. Disk space
doesn't vary significantly on a production database.

If we encourage that laziness then we will get reports that replication
doesn't work and Postgres crashes.

-- Simon Riggs           www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: current value support
Next
From: Peter Eisentraut
Date:
Subject: Re: How to pass around collation information