Re: Autovacuum does not stay turned off - Mailing list pgsql-performance

From Jerry Champlin
Subject Re: Autovacuum does not stay turned off
Date
Msg-id 48B4332B.4050207@absolute-performance.com
Whole thread Raw
In response to Re: Autovacuum does not stay turned off  (hubert depesz lubaczewski <depesz@depesz.com>)
Responses Re: Autovacuum does not stay turned off  (hubert depesz lubaczewski <depesz@depesz.com>)
List pgsql-performance
This makes sense.  What queries can I run to see how close to the limit we are?  We need to determine if we should stop the process which updates and inserts into this table until after the critical time this afternoon when we can perform the required maintenance on this table.

hubert depesz lubaczewski wrote:
On Tue, Aug 26, 2008 at 09:27:48AM -0600, Jerry Champlin wrote: 
Does anyone know what will cause this bahavior for autovacuum?   
http://www.postgresql.org/docs/current/interactive/runtime-config-autovacuum.html
-> autovacuum_freeze_max_age

depesz
 
Andrew Sullivan wrote:
On Tue, Aug 26, 2008 at 09:27:48AM -0600, Jerry Champlin wrote: 
Does anyone know what will cause this bahavior for autovacuum?   
You're probably approaching the wraparound limit in some database.  

If you think you can't afford the overhead when users are accessing
the system, when are you vacuuming?

A
 
We are changing the table structure tonight.  These two tables are very highly updated.  The goal is to use autovacuum but not have it take 10 days to run on a 13MM record table.

Thanks

-Jerry

pgsql-performance by date:

Previous
From: henk de wit
Date:
Subject: select on 22 GB table causes "An I/O error occured while sending to the backend." exception
Next
From: Tom Lane
Date:
Subject: Re: Query w empty result set with LIMIT orders of magnitude slower than without