Hi I have several such databases to issue vacuum on. If I were to vacuum each table individually, would the transaction id be updated after every table vacuum. Wonder if it is because I have several large partitioned tables that I drop every day that don't get vacuumed enough. -----Original Message----- From: Scott Marlowe [mailto:smarlowe@xxxxxxxxxxxxxxxxx] Sent: Wednesday, September 06, 2006 2:18 PM To: Sriram Dandapani Cc: Tom Lane; pgsql-admin@xxxxxxxxxxxxxx Subject: RE: [ADMIN] transactoin id wraparound problem On Wed, 2006-09-06 at 16:06, Sriram Dandapani wrote: > Curious why autovacuum does not handle this problem. Here are my > settings > > max_fsm_pages = 2000000 > > autovacuum = on # enable autovacuum > > autovacuum_naptime = 300 # time between autovacuum runs, > in > > autovacuum_vacuum_threshold = 10000 # min # of tuple updates before > # vacuum > autovacuum_analyze_threshold = 1500 # min # of tuple updates before > # analyze > autovacuum_vacuum_scale_factor = 0.4 # fraction of rel size before > # vacuum > autovacuum_analyze_scale_factor = 0.2 # fraction of rel size before > # analyze > autovacuum_vacuum_cost_delay = 100 > > autovacuum_vacuum_cost_limit = 1000 > > > The database has a constant rate of about 50-100G a day of data flowing > in which gets deleted after 2 days.(this cycle keeps repeating). There > are historical tables that grow at a rate of 2G-4G a day The most common cause of these problems is that you have long standing transactions that never get closed. Look for some connection to the database(s) (any of them) that are never committed or rolled back. One "idle in transaction" connection from one program can cause this problem. If you're doing your updates and / or deletes individually instead of in transactional batches that will just make it worse.
