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: 20060328161209.GJ75181@pervasive.com (view raw or flat)
Thread:
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
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(at)pervasive(dot)com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

In response to

Responses

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-2014 The PostgreSQL Global Development Group