Streaming Replication: Checkpoint_segment and wal_keep_segmentson standby
in [PgSql]
|
Prev: [BUGS] BUG #5487: dblink failed with 63 bytes connection names
Next: [HACKERS] Trigger function in a multi-threaded environment behavior
From: Heikki Linnakangas on 1 Jun 2010 03:14 On 31/05/10 18:14, Tom Lane wrote: > Heikki Linnakangas<heikki.linnakangas(a)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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |