Re: Streaming Replication: Checkpoint_segment and wal_keep_segments on standby

On 09/06/10 05:26, Fujii Masao wrote:
> On Wed, Jun 2, 2010 at 10:24 PM, Fujii Masao<masao.fujii@gmail.com>  wrote:
>> On Wed, Jun 2, 2010 at 8:40 PM, Heikki Linnakangas
>> <heikki.linnakangas@enterprisedb.com>  wrote:
>>> On 02/06/10 06:23, Fujii Masao wrote:
>>>>
>>>> On Mon, May 31, 2010 at 7:17 PM, Fujii Masao<masao.fujii@gmail.com>
>>>>   wrote:
>>>>>
>>>>> 4) Change it so that checkpoint_segments takes effect in standby mode,
>>>>> but not during recovery otherwise
>>>>
>>>> I revised the patch to achieve 4). This will enable checkpoint_segments
>>>> to trigger a restartpoint like checkpoint_timeout already does, in
>>>> standby mode (i.e., streaming replication or file-based log shipping).
>>>
>>> Hmm, XLogCtl->Insert.RedoRecPtr is not updated during recovery, so this
>>> doesn't work.
>>
>> Oops! I revised the patch, which changes CreateRestartPoint() so that
>> it updates XLogCtl->Insert.RedoRecPtr.
>
> This is one of open items. Please review the patch I submitted, and
> please feel free to comment!

Ok, committed with some cosmetic changes.

I thought hard if we should do this at all, since the original decision 
to do time-based restartpoints was deliberate. I concluded that the 
tradeoffs have changed enough since then to make this reasonable. We now 
perform restartpoints is bgwriter, so the replay will continue while the 
restartpoint is being performed, making it less disruptive than it used 
to be, and secondly SR stores the streamed WAL files in pg_xlog, making 
it important to perform restartpoints often enough to clean them up and 
avoid out-of-disk space.

BTW, should there be doc changes for this? I didn't find anything 
explaining how restartpoints are triggered, we should add a paragraph 
somewhere.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com