Fix checkpoint_timeout documentation to reflect current behavior.

Jeff Janes
This commit is contained in:
Robert Haas 2012-08-30 15:06:55 -04:00
parent 83fbfec383
commit 9bedfbd02b

View File

@ -422,12 +422,10 @@
linkend="guc-checkpoint-segments"> log segments, or every <xref linkend="guc-checkpoint-segments"> log segments, or every <xref
linkend="guc-checkpoint-timeout"> seconds, whichever comes first. linkend="guc-checkpoint-timeout"> seconds, whichever comes first.
The default settings are 3 segments and 300 seconds (5 minutes), respectively. The default settings are 3 segments and 300 seconds (5 minutes), respectively.
In cases where little or no WAL has been written, checkpoints will be In cases where no WAL has been written since the previous checkpoint, new
skipped even if checkpoint_timeout has passed. At least one new WAL segment checkpoints will be skipped even if checkpoint_timeout has passed.
must have been created before an automatic checkpoint occurs. The time If WAL archiving is being used and you want to put a lower limit on
between checkpoints and when new WAL segments are created are not related how often files are archived in order to bound potential data
in any other way. If file-based WAL shipping is being used and you want to
bound how often files are sent to standby server to reduce potential data
loss, you should adjust archive_timeout parameter rather than the checkpoint loss, you should adjust archive_timeout parameter rather than the checkpoint
parameters. It is also possible to force a checkpoint by using the SQL parameters. It is also possible to force a checkpoint by using the SQL
command <command>CHECKPOINT</command>. command <command>CHECKPOINT</command>.