On Fri, Apr 30, 2010 at 2:08 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > On Fri, 2010-04-30 at 13:52 -0400, Robert Haas wrote: >> On Fri, Apr 30, 2010 at 1:44 PM, Simon Riggs <si...@2ndquadrant.com> wrote: >> > On Fri, 2010-04-30 at 12:22 -0400, Bruce Momjian wrote: >> >> > >> >> > (wal_keep_segments can be changed without restarting, right?) >> >> >> >> Should we allow -1 to mean "keep all segments"? >> > >> > Why is that not called "max_wal_segments"? wal_keep_segments sounds like >> > its been through Google translate. >> >> Because it's not a maximum? > > I see the thinking, but why would you ever set it to be something that > is *less* than the existing numbers? That would be pointless and indeed, > does nothing. The only time you touch it at all is when you set it to be > a value higher than the number of files that would normally be kept, and > when that is the case it *will* be the maximum. > > So I say, max_wal_segments = 0 (default) meaning no limit, we just > rotate as needed. We put a comment in the docs to say that if a value is > selected less than 2*checkpoint_segments+1 then the value is overridden.
As you were quick to point out to me earlier this week, I am not an expert on our write-ahead logging system; however, I think you are mistaken. Perhaps Heikki could speak to the point more definitively, but I believe that the number of segments that the system retains for WAL archiving or crash recovery is variable. The purpose of this variable is to put a floor under the number of segments that are retained so that SR slaves can catch up if they fall behind. Of course, if archiving is configured, they can do that anyway using restore_command, but you might be running SR without archiving, or you might just want to set this to a small value so that the slaves don't have to keep switching between SR and archive recovery if segments get archived or checkpointed away at inconvenient times. It doesn't make a whole lot of sense to set the floor on the number of segments retained to positive infinity, except in one specific case: archiving is disabled, and you're trying to hang on to enough segments in pg_xlog to take a hot backup. As Tom said, it would be nice to have a more elegant solution to that problem, but we can do that in a future release; it's not really the primary purpose of wal_keep_segments, anyway. It certainly would not be a good idea to make the default configuration "retain all WAL forever". If you did that, a user who sets up PostgreSQL and is not using SR or HS or hot backups will eventually and inevitably fill up their hard disk. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers