A photorealistic 35mm photograph on Fuji Velvia film. A flock of male and female mallard ducks is being chased out of the front door a large, stately library by an Indian runner duck. The Indian runner duck is wearing librarian's spectacles. An old fashioned round clock is above the door

The archiver only runs when a WAL segment is complete. On a busy database that happens constantly; on a quiet one it might not happen for hours or days. archive_timeout exists to prevent the resulting “our database has been accepting writes all afternoon but none of them are in the archive yet” problem.

When set to a positive value, archive_timeout forces a WAL segment switch after that many seconds of elapsed time, provided there has been database activity in the interval. Default is 0 (disabled); context is sighup; units are seconds if unspecified. An idle server does nothing, because forcing rotations on an idle server would produce an endless stream of near-empty archives.

The tradeoff is file size. A WAL segment that gets rotated after 60 seconds of light activity is the same 16MB as a segment that rotated because it filled up. If your traffic pattern produces 200KB of WAL per minute and you set archive_timeout = 60s, you are archiving 16MB to capture 200KB, roughly forever. The docs’ warning that “a very short archive_timeout will bloat your archive storage” is doing real work.

So what’s reasonable? The docs say “a minute or so.” That is correct for most databases. The actual question you’re answering is: how much data are you willing to lose if the primary dies right now and your last unarchived segment goes with it? archive_timeout is the upper bound on that window. If the answer is “a minute,” set it to 60s. If the answer is “an hour,” set it to 3600s. If the answer is “less than a minute,” you do not want archive_timeout; you want streaming replication, which the docs explicitly recommend for this case and which gives you second-scale RPO without the padding waste.

One useful operational note: pg_switch_wal() does the same thing on demand. If you’re about to run a backup and want to ensure the last few seconds of activity make it to the archive, a manual switch costs you one mostly-empty segment and saves you the wait.

Recommendation: For most clusters with continuous archiving, set archive_timeout = 60s. If your RPO tolerance is looser, raise it. If it’s tighter than a minute, archiving is the wrong tool and you want a replica instead.