On Mon, Aug 16, 2010 at 2:47 PM, Peter Koczan <pjkoczan@gmail.com> wrote:
> On Mon, Aug 16, 2010 at 1:34 PM, Scott Marlowe <scott.marlowe@gmail.com> wrote:
>> If autovac is properly configured, very few, if any, PostgreSQL
>> databases need routine vacuuming jobs. However, other than sleep
>> states making it run slower, autovacuum is no different than a regular
>> old vacuum. Are you sure this wasn't a vacuum full, which is almost
>> never a desired operation to be regularly scheduled?
>
> I'm sure it wasn't a full vacuum. I almost never do those and when I
> do, I have to schedule downtime.
>
> I think another process got hung up somewhere and couldn't release its
> lock on the table in question, and there were several other processes
> waiting. It's possible that it was just a symptom of a larger problem
> at the time. I didn't have time to do a thorough analysis (and the
> problem state is lost now), and what was cause vs. effect is probably
> immaterial at this point.
OK then. It's important to understand that regular vacuum and
autovacuum perform the same functions and the only difference is the
default nap time. If you had a problem with vacuum, you can expect it
to crop up with autovacuum eventually too.
Note that I have had priority inversion issues with autovacuum, slony,
and the application where I work that meant I had to turn off
autovacuum to perform maintenance operations with slony. You might be
seeing the same kind of thing.
--
To understand recursion, one must first understand recursion.