From: Stephen Frost <sfrost@snowman.net>
To: Selva manickaraja <mavles78@gmail.com>
Cc: pgsql-admin@postgresql.org
Subject: Re: Too many WAL(s) despite low transaction
Date: Thu, 31 Mar 2011 21:38:53 -0400
Message-ID: <20110401013853.GC4116@tamriel.snowman.net> (raw)
In-Reply-To: <AANLkTi=U_2opbk3Kg223=++V9EfK5KGw-M-28Ec0dxCe@mail.gmail.com>
References: <AANLkTi=Vc91VMA1_w3e6yV0gmAL1xgbogj9p1fW3zmQ=@mail.gmail.com>
<20110401004240.GA4116@tamriel.snowman.net>
<AANLkTik9S-bB0nhAzUWED0vKS_JgF3RkZd0JPNq-C-Yn@mail.gmail.com>
<20110401010336.GB4116@tamriel.snowman.net>
<AANLkTi=U_2opbk3Kg223=++V9EfK5KGw-M-28Ec0dxCe@mail.gmail.com>
Selva,
* Selva manickaraja (mavles78@gmail.com) wrote:
> If our check_timeout is 30 minutes, what would be an acceptable time limit
> for archive_timeout?
They're two different things. Checkpoints are about getting data
flushed out to the data files (so they're not just in the WALs),
archive_timeout is about how often WAL segments should be forcibly
archived (so that the archive server doesn't end up missing data on
low-write systems).
Typically, I'd pick archive_timeout of around 5m or 10m, depending on
how much time you don't mind losing. I'd also compress the WALs (on a
low-write system, they're going to have very little data in them).
There's also a utility out there, iirc, which will truncate WALs to
remove empty space.
> Also since bulk loading/migration of large amount of data was done earlier,
> do I need to run vacuum etc.
Erm, you should be running autovacuum..
Stephen
Attachments:
signature.asc (application/pgp-signature, 197B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: sfrost@snowman.net, mavles78@gmail.com
Subject: Re: Too many WAL(s) despite low transaction
In-Reply-To: <20110401013853.GC4116@tamriel.snowman.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox