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. -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
