Re: [GENERAL] PANIC: heap_update_redo: no block

Поиск
Список
Период
Сортировка
От Jim C. Nasby
Тема Re: [GENERAL] PANIC: heap_update_redo: no block
Дата
Msg-id 20060328161209.GJ75181@pervasive.com
обсуждение исходный текст
Ответ на Re: [GENERAL] PANIC: heap_update_redo: no block  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [GENERAL] PANIC: heap_update_redo: no block  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, Mar 28, 2006 at 10:07:35AM -0500, Tom Lane wrote:
> 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.

Would the suggestion made in
http://archives.postgresql.org/pgsql-hackers/2005-05/msg01374.php help
in this regard? (Sorry, much of this is over my head, but not everyone
may have read that...)
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: Why are default encoding conversions
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Why are default encoding conversions