From: | "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [GENERAL] PANIC: heap_update_redo: no block |
Date: | 2006-03-29 02:59:29 |
Message-ID: | e0ctco$fl1$1@news.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote
>
> What we should be seeing, and don't see, is an indication of a backup
> block attached to this WAL record. Furthermore, I don't see any
> indication of a backup block attached to *any* of the WAL records in
> Alex's printout. The only conclusion I can draw is that he had
> full_page_writes turned OFF, and as we have just realized that that
> setting is completely unsafe, that is the explanation for his failure.
>
This might be the answer. I tried the fill-checkpoint-vacuum-crash sequence
as you suggested, but still a neat recovery. That's because, IMHO, even
after checkpoint, the moved page will still be saved into WAL (since it is
new again to the checkpoint) if full_page_writes is on.
Regards,
Qingqing
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Travers | 2006-03-29 03:02:48 | Re: Guidelines for upgrading from pgsql7.4.xxx server to |
Previous Message | Luki Rustianto | 2006-03-29 02:53:31 | Guidelines for upgrading from pgsql7.4.xxx server to pgsql8.xxx server |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-03-29 03:32:28 | Re: Exposing DEFAULT_PGSOCKET_DIR via a libpq function? |
Previous Message | Greg Sabino Mullane | 2006-03-29 02:38:37 | Re: Bytea and perl |