Re: PANIC: corrupted item lengths

From: Greg Stark <stark(at)enterprisedb(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PANIC: corrupted item lengths
Date: 2009-06-04 14:01:47
Message-ID: 4136ffa0906040701qa1785abi5ee3363ce5c5363@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 4, 2009 at 2:55 PM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:

> I tend to hate automatic zeroing of pages because there's no way to get
> the contents later for forensics.

That's why we default to zero_damaged_pages=false. Saving the pages
somewhere seems like it would be a good feature to add for
zero_damaged_pages in general but an orthogonal issue.

Simon's suggestion is a few more cases we could catch send through the
zero_damaged_pages code path rather than crashing. If his analysis of
the existing code is correct -- I haven't looked but I assume so --
then that sounds like the right thing to do.

I would be concerned about the overhead of checking this on all the
line pointers if we're just trying to look up a single item. But from
the sound of his description it would only fire in the hot pruning for
which we already control the frequency.

--
greg

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-06-04 14:02:34 Re: PANIC: corrupted item lengths
Previous Message Alvaro Herrera 2009-06-04 13:55:23 Re: PANIC: corrupted item lengths