Re: 8.2.3 PANIC with "corrupted item pointer" - Mailing list pgsql-general

From Henka
Subject Re: 8.2.3 PANIC with "corrupted item pointer"
Date
Msg-id 61515.196.23.181.69.1182431159.squirrel@support.metroweb.co.za
Whole thread Raw
In response to Re: 8.2.3 PANIC with "corrupted item pointer"  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: 8.2.3 PANIC with "corrupted item pointer"  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-general

>> I'm using PG 8.2.3:
>
> You should update to 8.2.4, it includes a security fix and several bug
> fixes.

That was my next option.  My last backup dump looks suspiciously small,
but the day before that looks about right.


> My first thought is bad memory. It's always good to rule that out since
> it's
> quite common and can cause a lot of hair-pulling. If you can schedule some
> downtime download memtest86 and run it overnight.

Thanks for the suggestion - will give it a try.


> Other than that it might be interesting to know the values of some server
> parameters: "fsync" and "full_page_writes". Have you ever had this machine
> crash or had a power failure? And what kind of i/o controller is this?

fsync = off
full_page_writes = default

Sadly yes, the machine has experienced a power failure about 3 weeks ago
(genset startup problem).  With fsync=off this presents a problem wrt safe
recovery, I know...


> Ideally it would be good to get a dump of this block, it looks like it's
> probably a block of an index (unless you have a table with extremely
> narrow
> rows?). But there doesn't seem to be enough information in this error to
> tell
> which block it happened on.
>
> If you manually "vacuum verbose" each table does it cause a crash? If so
> send

Giving that a try now on the suspect table.




pgsql-general by date:

Previous
From: Bruce McAlister
Date:
Subject: Re: Recovery/Restore and Roll Forward Question.
Next
From: Gregory Stark
Date:
Subject: Re: 8.2.3 PANIC with "corrupted item pointer"