Hi Tom,
I had a problem recently with an index on my category_product table.
A few times when I was vacuuming that table, I had forgotten to reset
our statement_timeout setting from 2 minutes to 0, so a few times
the statement was cancelled pre-maturely due to the timeout setting.
Perhaps that caused the problem. I deleted the index and was able to
vacuum the table correctly. Prior to dropping the index, the database
did crash on me before I figured out what the problem was.
As a side note, we do have autovacuum turned on, but it doesn't seem
to kick in for tables that have a very large number of frequent updates.
The category_product table gets updated once every half an hour.
Vacuuming often finds over 300,000 row versions to delete. So that's
why I've been going in and running vacuum analyze manually. I know
I should probably add it to the end of the task that updates the table.
Thanks,
____________________________________________________________________
Brendan Duddridge | CTO | 403-277-5591 x24 | brendan@xxxxxxxxxxxxxx
ClickSpace Interactive Inc.
Suite L100, 239 - 10th Ave. SE
Calgary, AB T2G 0V9
http://www.clickspace.com
On Apr 19, 2006, at 9:02 AM, Tom Lane wrote:
Brendan Duddridge <brendan@xxxxxxxxxxxxxx> writes:
I was doing a vacuum analyze verbose on my database today and I
noticed the following message printed out:
WARNING: relation "category_product" page 128979 is uninitialized
--- fixing
WARNING: relation "category_product" page 128980 is uninitialized
--- fixing
...
There are some situations in which this is expected, which is why
VACUUM deals with it, but none of them are very good: they involve
backends adding a page to a table and then failing before they can
write a WAL record about initializing the page. Have you had any
crashes recently?
regards, tom lane
---------------------------(end of
broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
