Re: Allow wal_keep_segments to keep all segments

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Simon Riggs <simon@2ndquadrant.com>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, Fujii Masao <masao.fujii@gmail.com>, Alvaro Herrera <alvherre@commandprompt.com>, Josh Berkus <josh@agliodbs.com>, pgsql-hackers@postgresql.org
Date: 2010-06-02T19:31:29Z
Lists: pgsql-hackers
On Wed, Jun 2, 2010 at 3:20 PM, Bruce Momjian <bruce@momjian.us> wrote:
> Bruce Momjian wrote:
>> Robert Haas wrote:
>> > On Sat, May 8, 2010 at 10:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> > > Bruce Momjian <bruce@momjian.us> writes:
>> > >> Uh, did we decide that 'wal_keep_segments' was the best name for this
>> > >> GUC setting? ?I know we shipped beta1 using that name.
>> > >
>> > > I thought min_wal_segments was a reasonable proposal, but it wasn't
>> > > clear if there was consensus or not.
>> >
>> > I think most people thought it was another reasonable choice, but I
>> > think the consensus position is probably something like "it's about
>> > the same" rather than "it's definitely better".  We had one or two
>> > people with stronger opinions than that on either side, I believe.
>>
>> Agreed the current name seems OK.  However, was there agreement that
>> wal_keep_segments = -1 should keep all WAL segements?  I can see that as
>> useful for cases where you are doing a dump to be transfered to the
>> slave, and not using archive_command.  This avoids the need for the "set
>> a huge value" solution.
>
> 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.

+1 for the patch, but why wait until after beta2?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company