Re: PANIC: corrupted item lengths

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PANIC: corrupted item lengths
Date: 2009-06-04 14:02:34
Message-ID: 13164.1244124154@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> What seems strange about the various errors generated in bufpage.c is
> that they are marked as ERRORs, yet are executed within a critical
> section causing the system to PANIC.

The reason we PANIC there is to reduce the probability that bad data
will be written back to disk. Of course, if the bad data was read off
disk in the first place, there's no hope --- but we have checks on
incoming pages for that. What seems significantly more likely if we
detect a problem here is that we somehow corrupted the page while it
sits in shared buffers. So, there's some hope that the corruption will
not get back to disk, so long as we PANIC and thereby cause
shared-memory contents to be flushed.

> Votes?

+1 for no change.

We could make the page-read-time validation checks stricter, if there's
some specific pattern you're seeing that gets past those checks now.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-06-04 14:12:21 Re: It's June 1; do you know where your release is?
Previous Message Greg Stark 2009-06-04 14:01:47 Re: PANIC: corrupted item lengths