Skip site navigation (1) Skip section navigation (2)

Re: [GENERAL] PANIC: heap_update_redo: no block

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, 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 16:12:09
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-hackers
On Tue, Mar 28, 2006 at 10:07:35AM -0500, Tom Lane wrote:
> 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.

Would the suggestion made in 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(at)pervasive(dot)com
Pervasive Software    work: 512-231-6117
vcard:       cell: 512-569-9461

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2006-03-28 16:24:51
Subject: Re: Why are default encoding conversions
Previous:From: Tatsuo IshiiDate: 2006-03-28 16:09:08
Subject: Re: Why are default encoding conversions

pgsql-general by date

Next:From: Scott MarloweDate: 2006-03-28 16:26:26
Subject: Re: table owner of cloned databases
Previous:From: Tom LaneDate: 2006-03-28 15:56:16
Subject: Re: More AIX 5.3 fun - out of memory ?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group