Re: [GENERAL] PANIC: heap_update_redo: no block

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Alex bahdushka" <bahdushka(at)gmail(dot)com>
Cc: "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [GENERAL] PANIC: heap_update_redo: no block
Date: 2006-03-27 15:22:49
Message-ID: 14448.1143472969@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

[ redirecting to a more appropriate mailing list ]

"Alex bahdushka" <bahdushka(at)gmail(dot)com> writes:

> LOG: REDO @ D/19176610; LSN D/19176644: prev D/191765E8; xid 81148979: Heap - clean: rel 1663/16386/16559898; blk 0
> LOG: REDO @ D/19176644; LSN D/191766A4: prev D/19176610; xid 81148979: Heap - move: rel 1663/16386/16559898; tid 1/1; new 0/10
> PANIC: heap_update_redo: no block: target blcknum: 1, relation(1663/16386/16559898) length: 1

I think what's happened here is that VACUUM FULL moved the only tuple
off page 1 of the relation, then truncated off page 1, and now
heap_update_redo is panicking because it can't find page 1 to replay the
move. Curious that we've not seen a case like this before, because it
seems like a generic hazard for WAL replay.

The simplest fix would be to treat WAL records as no-ops if they refer
to nonexistent pages, but that seems much too prone to hide real failure
conditions. Another thought is to remember that we ignored this record,
and then complain if we don't see a TRUNCATE that would've removed the
page. That would be pretty complicated but not impossible. Anyone have
a better idea?

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2006-03-27 15:38:10 Re: Bug? was: Re: ERROR: could not convert UTF8 character to ISO8859-1
Previous Message Ardian Xharra (Boxxo) 2006-03-27 15:06:36 Creating serial ID on Windows.

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-03-27 15:26:47 Re: Recovery from multi trouble
Previous Message Dave Page 2006-03-27 14:30:11 Re: Remote administration contrib module