Message-ID: <4CC1CB0F.7050006@agliodbs.com>
Date: Fri, 22 Oct 2010 10:34:07 -0700
From: Josh Berkus <josh@agliodbs.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.9pre) Gecko/20100217 Shredder/3.0.3pre
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: Re: Simplifying replication
References: <201010220058.o9M0waa06053@momjian.us>
	<4CC0E465.4000700@agliodbs.com>
	<AANLkTineXrnRAkRV4Cs=rmSo0QkWkFRVYQpj0AWXGn2=@mail.gmail.com>
	<4CC0F10D.3000201@agliodbs.com>
	<AANLkTi=Nz06NGkUAEzJ7r=CMRsiUAJXRsWALqw-jZ62A@mail.gmail.com>
	<4CC1C74E.8080409@agliodbs.com> <26273.1287768288@sss.pgh.pa.us>
In-Reply-To: <26273.1287768288@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


>> max_wal_size
>> min_wal_size
>
> [ scratches head... ]  What's the functional effect of min_wal_size, exactly?

Replaces wal_keep_segments. The rename is to make the GUCs obviously 
symmetrical, and to make it clear that the *meaning* of the variable has 
changed.

>> Even better would be to replace min_wal_size with min_wal_time, which
>> would set a time span for the oldest WAL segment to be kept (up to
>> max_wal_size - 2).   Hmmm.  That doesn't seem that hard to implement.
>> Is it?
>
> Um, what happens when honoring min_wal_time conflicts with honoring
> max_wal_size?

When we get close enough to max_wal_size (we'll need a couple segments 
of leeway, I think), we start recycling WAL segments even if they are 
less that min_wal_time old.  This is under the presumption that most 
DBAs will prefer having the standby desyncrhonize to having the master 
lock up due to running out of disk space.  Presumably if such recycling 
happens we'd also write a WARNING to the logs.

-- 
                                   -- Josh Berkus
                                      PostgreSQL Experts Inc.
                                      http://www.pgexperts.com