From: | "Brett W(dot) McCoy" <bmccoy(at)chapelperilous(dot)net> |
---|---|
To: | Denis Perchine <dyp(at)perchine(dot)com> |
Cc: | Esa Pikkarainen <epikkara(at)ktk(dot)oulu(dot)fi>, <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: a "huge" table with small rows and culumns |
Date: | 2000-12-19 13:13:03 |
Message-ID: | Pine.LNX.4.30.0012190808340.17179-100000@chapelperilous.net |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, 19 Dec 2000, Denis Perchine wrote:
> Yes, this is standard method. But there is really bad deadlock inside 7.0.x
> code. And it is possible that if you have high load on database, vacuum will
> just locked waiting for a lock, while some other backend will need lock
> vacuum have for other operation. This fixed in current CVS a month ago, but
> there is no patch for 7.0.x. I am not so sure in my knowledge of postgresql
> internals to fix this. If you are not worry, you can run on 7.1.x (I would
> not recommend this).
>
> All above means that there is no real solutions. If your database is not
> heavily loaded you will never see such problems. I saw them each day until I
> did not remove vacuum from crontab. I do it manually now.
This is why I suggested doing overnight when there may be little or no
load on the database. If it's a backend to a website that could possibly
be used 24/7, obviously this can be a problem, unless you schedule and
announce a short downtime once a week for maintenance or however often you
need to vacuum.
Probably a good idea to run a back up during the same downtime, before the
vacuum is run. :-)
-- Brett
http://www.chapelperilous.net/~bmccoy/
---------------------------------------------------------------------------
Each of us bears his own Hell.
-- Publius Vergilius Maro (Virgil)
From | Date | Subject | |
---|---|---|---|
Next Message | Martin A. Marques | 2000-12-19 13:19:51 | grant a db |
Previous Message | Denis Perchine | 2000-12-19 12:51:55 | Re: a "huge" table with small rows and culumns |