On 31/05/10 18:14, Tom Lane wrote:
Heikki Linnakangas<heikki.linnakan...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
