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
Re: [GENERAL] PANIC: heap_update_redo: no block |
Список | 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 по дате отправления: