Re: [GENERAL] PANIC: heap_update_redo: no block - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [GENERAL] PANIC: heap_update_redo: no block
Date
Msg-id 1689.1143558455@sss.pgh.pa.us
Whole thread Raw
In response to Re: [GENERAL] PANIC: heap_update_redo: no block  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: [GENERAL] PANIC: heap_update_redo: no block  ("Jim C. Nasby" <jnasby@pervasive.com>)
Re: [GENERAL] PANIC: heap_update_redo: no block  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
Simon Riggs <simon@2ndquadrant.com> writes:
> On Mon, 2006-03-27 at 22:03 -0500, Tom Lane wrote:
>> The subsequent replay of the deletion or truncation
>> will get rid of any unwanted data again.

> Trouble is, it is not a watertight assumption that there *will be* a
> subsequent truncation, even if it is a strong one.

Well, in fact we'll have correctly recreated the page, so I'm not
thinking that it's necessary or desirable to check this.  What's the
point?  "PANIC: we think your filesystem screwed up.  We don't know
exactly how or why, and we successfully rebuilt all our data, but
we're gonna refuse to start up anyway."  Doesn't seem like robust
behavior to me.  If you check the archives you'll find that we've
backed off panic-for-panic's-sake behaviors in replay several times
before, after concluding they made the system less robust rather than
more so.  This just seems like another one of the same.

> Perhaps we do have one systemic problem: systems documentation.

I agree on that ;-).  The xlog code is really poorly documented.
I'm going to try to improve the comments for at least the xlogutils
routines while I'm fixing this.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Tru64/Alpha problems
Next
From: Tom Lane
Date:
Subject: Re: Tru64/Alpha problems