Jay at Verizon wrote
> checkpoint_timeout = 5min #default
This impacts the primary machine only and ensures that regardless of the
lack of activity a crash will only need to REDO that last five minutes of
history since everything prior to that will already have been persisted to
the data files.
> archive_timeout=3600
This impacts how far, in time, the archive can be behind the master in a
low-volume situation. This is because only complete (16MB) WAL files are
shipped. In a low volume situation it may take several active
checkpoint_timeout periods (not to mention zero activity periods) to
generate enough data to fill up a single 16MB file.
In a low volume situation a single WAL will have multiple checkpoint
records. In a high volume situation there will be many WAL files that have
no checkpoint records. This later situation being the reason for the
"checkpoint_segments" parameter.
So the archive will never be more than 16MB behind the master but the
corresponding time period is unbounded in the absence of archive_timeout.
The master will always be up-to-date but the amount of time needed for
recovery is bounded either by time or size - which ever one comes first.
David J.
--
View this message in context:
http://postgresql.nabble.com/9-2-documentation-configuration-question-tp5828964p5828990.html
Sent from the PostgreSQL - admin mailing list archive at Nabble.com.