You can check the running processes and grep aotovacuum.
You should see a launcher process which is always running.
If you use pgAdmin you can also look at the table statistics from the GUI and see when was the last time autovacuum or autoanalyze ran on each table.
From: pgsql-admin-owner@postgresql.org [mailto:pgsql-admin-owner@postgresql.org] On Behalf Of Selva manickaraja Sent: Thursday, March 31, 2011 9:25 PM To: Stephen Frost Cc: pgsql-admin@postgresql.org Subject: Re: [ADMIN] Too many WAL(s) despite low transaction
On Fri, Apr 1, 2011 at 10:35 AM, Stephen Frost <sfrost@snowman.net> wrote:
> Where you mentioned "after the reload" I suppose you meant restart right?
I'm not sure offhand if it requires a reload or a restart, that's why I suggested doing a reload than then checking the logs to see if a restart is required.
I have put it in. Log file does not complaint, neither do I see the WAL(s) reducing. So I'm waiting for Friday lunch time in 1 hour to restart the db.
> About compressing you mentioned iirc, but how do I use it? are there any > examples. I read about pg_compress before. Is that same?
No, I meant "use gzip".
OK, I saw a sample in the PostgreSQL site, I will try that on the development machine first.
> The configuration file shows that autovacuum=on and track_count=on to be > commented out. That means that it is not running right? If that's the case, > just uncommenting it now should get it working right?
Commented out means that the default value is used, which is on for both of those. That means that autovacuum should already be running. Is there some reason you think it isn't?
I see. Cause I was thinking that all these surge of WAL was due to the fact that autovacuum was not running. Is there a utility to check if autovacuum is running or not?
Once the db is restarted, I will post the results to you to let you know how well the WAL(s) are fairing.
