On Mon, May 31, 2010 at 6:37 PM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > 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.
Right. > 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: > > 1) Leave it as it is, checkpoint_segments doesn't do anything during > recovery/standby mode > > 2) Change it so that checkpoint_segments does take effect during > recover/standby > > 3) Change it so that checkpoint_segments takes effect during streaming > replication, but not during recovery otherwise > > I'm leaning towards 3), it still seems reasonable to not slow down recovery > when recovering from archive, but the potential for out of disk space > warrants doing 3. 3) makes sense. But how about 4)? 4) Change it so that checkpoint_segments takes effect in standby mode, but not during recovery otherwise This would lessen the time required to restart the standby also in file-based log shipping case. Of course, there is the tradeoff between the speed of recovery and the recovery time. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers