page is uninitialized?

Hi,

Shortly after posting this message, I received the following error also:

PANIC: right sibling is not next child in
"category_product__is_active_idx"
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

Are the two related in anyway? I'm starting to feel like my database
is falling apart at the seams.

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 2:16 AM, Brendan Duddridge wrote:

It turns out I had a bad index on my category_product table. I
dropped the index, then reindexed the whole table, then I was
able to successfully vacuum analyze.

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 2:23 AM, Brendan Duddridge wrote:

Brendan Duddridge <brendan@clickspace.com> writes:

Shortly after posting this message, I received the following error also:
PANIC: right sibling is not next child in
"category_product__is_active_idx"

Last week's report of that same error was traced to running with
full_page_writes turned off; are you doing that? If so, don't.
http://archives.postgresql.org/pgsql-bugs/2006-04/msg00135.php
http://archives.postgresql.org/pgsql-announce/2006-04/msg00002.php

regards, tom lane

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

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: