Re: [GENERAL] PANIC: heap_update_redo: no block

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [GENERAL] PANIC: heap_update_redo: no block
Дата
Msg-id 1689.1143558455@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [GENERAL] PANIC: heap_update_redo: no block  (Simon Riggs <simon@2ndquadrant.com>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Tru64/Alpha problems
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Tru64/Alpha problems