*** a/doc/src/sgml/config.sgml --- b/doc/src/sgml/config.sgml *************** *** 1902,1907 **** SET ENABLE_SEQSCAN TO OFF; --- 1902,1908 ---- for standby purposes, and the number of old WAL segments available for standbys is determined based only on the location of the previous checkpoint and status of WAL archiving. + This parameter has no effect on a restartpoint. This parameter can only be set in the postgresql.conf file or on the server command line. *** a/doc/src/sgml/wal.sgml --- b/doc/src/sgml/wal.sgml *************** *** 424,429 **** --- 424,430 ---- There will always be at least one WAL segment file, and will normally not be more than (2 + checkpoint_completion_target) * checkpoint_segments + 1 + or checkpoint_segments + + 1 files. Each segment file is normally 16 MB (though this size can be altered when building the server). You can use this to estimate space requirements for WAL. *************** *** 436,441 **** --- 437,458 ---- + In archive recovery or standby mode, the server periodically performs + restartpointsrestartpoint + which are similar to checkpoints in normal operation: the server forces + all its state to disk, updates the pg_control file to + indicate that the already-processed WAL data need not be scanned again, + and then recycles old log segment files if they are in the + pg_xlog directory. Note that this recycling is not affected + by wal_keep_segments at all. A restartpoint is triggered, + if at least one checkpoint record has been replayed since the last + restartpoint, every checkpoint_timeout seconds, or every + checkoint_segments log segments only in standby mode, + whichever comes first. In log shipping case, the checkpoint interval + on the standby is normally smaller than that on the master. + + + There are two commonly used internal WAL functions: LogInsert and LogFlush. LogInsert is used to place a new record into