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@clickspace.com
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@clickspace.com> 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
>