From: | mattcwood <mattcwood(at)gmail(dot)com> |
---|---|
To: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: PITR archive_timeout Command |
Date: | 2009-08-11 18:48:29 |
Message-ID: | 24923536.post@talk.nabble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Ian Lea wrote:
>
> The advantage of setting it high is that you'll use less disk space
> and have fewer files to archive.
>
> The disadvantage of setting it high is that you might lose more data.
>
This is not *entirely* true. The archive_timeout setting only indicates the
time at which a new WAL archive is forced, no matther how much data has been
written. If a WAL file fills up before the timeout is reached, it will fire
the archive_command immediately and the timeout "timer" is reset.
For example, we have a primary database instance where we see the
archive_command fire every 1-2 minutes during peak, but our archive_timeout
is set to 15 minutes. This ensures that the secondary database instance is
getting updated even when there's not enough write traffic to fill up a WAL
file.
--Matthew Wood
--
View this message in context: http://www.nabble.com/PITR-archive_timeout-Command-tp24788681p24923536.html
Sent from the PostgreSQL - admin mailing list archive at Nabble.com.
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Kempter | 2009-08-11 20:13:03 | insert a backslash into a bytea field? |
Previous Message | Kevin Grittner | 2009-08-11 17:35:59 | Re: replay WAL segments without a "base backup" ? |