On 31/05/10 18:14, Tom Lane wrote:
> Heikki Linnakangas<heikki.linnakangas@enterprisedb.com> writes:
>> The central question is whether checkpoint_segments should trigger
>> restartpoints or not. When PITR and restartpoints were introduced, the
>> answer was "no", on the grounds that when you're doing recovery you're
>> presumably replaying the logs much faster than they were generated, and
>> you don't want to slow down the recovery by checkpointing too often.
>
>> Now that we have bgwriter active during recovery, and streaming
>> replication which retains the streamed WALs so that we now risk running
>> out of disk space with long checkpoint_timeout, it's time to reconsider
>> that.
>
>> I think we have three options:
>
> What about
>
> (4) pay some attention to the actual elapsed time since the last
> restart point?
>
> All the others seem like kluges that are relying on hard-wired rules
> that are hoped to achieve something like a time-based checkpoint.
Huh? We already do time-based restartpoints, there's nothing wrong with
that logic AFAIK. The problem that started this thread is that we don't
do WAL-space consumption based restartpoints, i.e. checkpoint_segments
does nothing in standby mode.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
