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
|
Список | 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 по дате отправления: