Re: Buglist

After a long battle with technology,khera@kcilink.com (Vivek Khera), an earthling, wrote:
>>>>>> "TL" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>
> TL> Just nice'ing the VACUUM process is likely to be counterproductive
> TL> because of locking issues (priority inversion).  Though if anyone cares
> TL> to try it on a heavily-loaded system, I'd be interested to hear the
> TL> results...
>
> tried it once.  didn't make much difference except that vacuum took
> longer than normal.  i didn't see any deadlocks.
>
> i actually figured out what my main problem was.  vacuum every 6 hours
> on my two busiest tables was taking longer than 6 hours when we were
> very busy...

I "wedged" a database server once that way; it was busy, busy, busy
with a multiplicity of processes trying to simultaneously vacuum the
same table.

The "new generation" resolution to that is pg_autovacuum; if you're
running a pre-7.3 version, a good idea is basically to have a vacuum
script that checks a "lock file" and exits if it sees that another
process is already busy vacuuming.
--
output = reverse("gro.mca" "@" "enworbbc")
http://www.ntlug.org/~cbbrowne/postgresql.html
"I am aware of the benefits  of a micro kernel approach.  However, the
fact remains  that Linux is  here, and GNU  isn't --- and  people have
been working on Hurd for a lot longer than Linus has been working on
Linux." -- Ted T'so, 1992.