From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, Alex bahdushka <bahdushka(at)gmail(dot)com>, Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [GENERAL] PANIC: heap_update_redo: no block |
Date: | 2006-03-28 15:07:35 |
Message-ID: | 1689.1143558455@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Simon Riggs <simon(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | beer | 2006-03-28 15:14:37 | Re: Issues with restoring |
Previous Message | Holger Hoffstaette | 2006-03-28 14:33:46 | Re: PostgreSQL's XML support comparison against other RDBMSes |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-03-28 15:24:55 | Re: Tru64/Alpha problems |
Previous Message | Andrew Dunstan | 2006-03-28 13:58:51 | Tru64/Alpha problems |