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