Re: pg_start_backup and pg_stop_backup Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct

On Fri, Apr 30, 2010 at 2:08 PM, Simon Riggs <simon(at)2ndquadrant(dot)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 <simon(at)2ndquadrant(dot)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