From: | "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: PANIC: heap_update_redo: no block |
Date: | 2006-03-27 12:52:11 |
Message-ID: | e08nc2$2jvd$1@news.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
""Alex bahdushka"" <bahdushka(at)gmail(dot)com> wrote
>
> 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
>
What happened that time is like this: heap 16559898 has two pages {0, 1}. A
vacuum full first examines page 0, do some cleaning; then it comes to the
second page, move the item 1/1 to page 0 -- as a byproduct, the heap is
truncated to only 1 page since 1/1 is the only item on the second page. At
this time, system crashed, and heap 16559898 has only 1 page left. At the
xlog startup time, for some unknown reason( or I am totally wrong),
PostgreSQL didn't extend the heap to 2 blocks, thus the
heap_update_redo(more exactly, should be heap_move_redo) failed. But what's
the unknown reason, I really don't have a clue :-(.
Actually I tried to simulate your situation, but everytime I got a neat
recovery -- the only carvet is that depends on the XLOG_SMGR_TRUNCATE
written down or not, there may one extra useless page at the end of heap,
which is not a problem at all.
Regards,
Qingqing
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2006-03-27 12:57:05 | Re: What to index to speed up my UNION views? |
Previous Message | Jim C. Nasby | 2006-03-27 12:51:26 | Re: ambulkdelete |
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2006-03-27 13:12:52 | Remote administration contrib module |
Previous Message | Thomas Hallgren | 2006-03-27 12:48:23 | Re: Shared memory |