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