Re: page is uninitialized?

From: Brendan Duddridge <brendan(at)clickspace(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-general General <pgsql-general(at)postgresql(dot)org>
Subject: Re: page is uninitialized?
Date: 2006-04-19 15:29:18
Message-ID: 4C0053FF-E176-4EF7-BB5B-9C00BA9B4ED6@clickspace.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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(at)clickspace(dot)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(at)clickspace(dot)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
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Mauricio Mantilla 2006-04-19 15:39:16 help plpgsql, cursors, fetch into
Previous Message Alban Hertroys 2006-04-19 15:02:25 Re: Categories and Sub Categories (Nested)