Re: 8.2.3 PANIC with "corrupted item pointer"

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Henka" <henka(at)cityweb(dot)co(dot)za>
Cc: <pgsql-general(at)postgresql(dot)org>
Subject: Re: 8.2.3 PANIC with "corrupted item pointer"
Date: 2007-06-21 11:35:06
Message-ID: 87y7idzgk5.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Henka" <henka(at)cityweb(dot)co(dot)za> writes:

> Hello all,
>
> I'm using PG 8.2.3:

You should update to 8.2.4, it includes a security fix and several bug fixes.
However afaik none of them look like this.

> PANIC: corrupted item pointer: offset = 3308, size = 28
> LOG: autovacuum process (PID 18165) was terminated by signal 6

Huh, that's pretty strange.

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.

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?

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
that along and at least we'll know which table or index has the corrupted
data. You probably don't want to do this during peak production time though...

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bruce McAlister 2007-06-21 12:03:07 Re: Recovery/Restore and Roll Forward Question.
Previous Message Gregory Stark 2007-06-21 11:05:10 Re: Accent insensitive search