Skip site navigation (1) Skip section navigation (2)

Re: autovacuum hung?

From: Brian Cox <brian(dot)cox(at)ca(dot)com>
To: "Tom Lane [tgl(at)sss(dot)pgh(dot)pa(dot)us]" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: autovacuum hung?
Date: 2009-05-31 19:08:25
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Tom Lane [tgl(at)sss(dot)pgh(dot)pa(dot)us] wrote:
> They might have been blocked behind some other process that was sitting
> in an open transaction for some reason.  The other likely cause is badly
> chosen autovacuum delay, but I think that was already covered.
Well, after I noticed this running for a while, I shutdown the postgres 
port and restarted postgres. The autovacuum of these tables kicked in 
promptly when postgres was back up. I then let them run. So, I don't 
think that surmise #1 is likely.
As for #2, I'm using the default. These tables get updated once a day 
with each row (potentially) being updated 1-24 times over many minutes 
to a handful of hours. Dp you think it would be better to manually 
vacuum these tables? If so, would it be best to disable autovacuum of 
them? And while I'm at it, if you disable autovacuum of the master table 
will that disable it for the actual partitions?

  > Don't assume every row in pg_locks has a join partner in pg_class.
> You could use an outer join ...
Yes, of course. It never occurred that there could be db locks not 
associated with tables.



pgsql-performance by date

Next:From: Tom LaneDate: 2009-05-31 19:34:37
Subject: Re: autovacuum hung?
Previous:From: Tom LaneDate: 2009-05-31 17:32:07
Subject: Re: autovacuum hung?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group