Re: PANIC: heap_update_redo: no block

From: "Alex bahdushka" <bahdushka(at)gmail(dot)com>
To: "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: PANIC: heap_update_redo: no block
Date: 2006-03-20 17:54:46
Message-ID: e0bf43760603200954p57dc0e83x6f956895fa3df957@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On 3/20/06, Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu> wrote:
>
> ""Alex bahdushka"" <bahdushka(at)gmail(dot)com> wrote
> >
> > After doing some more digging, it looks like that server was missing
> > the appropriate Kpostgresql symlink in /etc/rc0.d/. So upon shutdown
> > (shutdown -h now)... my guess is it got a sigterm (you know where it
> > says Sending all processes a TERM signal or whatever), then it (init)
> > waited 5 seconds or whatever the timeout is and sent a sigkill.
> >
> > If postgresql took longer to shutdown than that timeout and so was
> > then given a sigkill and then server turned off.... Could that do it?
> >
>
> I don't believe in this explaination actually. According the startup
> message, the error "heap_update_redo: no block" could most possibly happen
> when PostgreSQL tried to read an existing block but found that the file
> length is not long enough to have it. How could a SIGKILL truncate a data
> file like that?
>

Hrm... well i obviously have restored the database by now (using
pg_resetxlog; pg_dump; initdb; pg_restore). However i did make a
backup of the broken directory before I created the new database. If
anyone has any thing they would like me to try to possibly help track
down this possible bug. I would be more than glad to do it.

Since it sounds like its something wrong with the xlog here is the
contents of the dir... Im not sure how useful this is but here it is
anyways.

pg_xlog# du -ak
16404 ./000000010000000D00000022
16404 ./000000010000000D0000001E
16404 ./000000010000000D00000019
16404 ./000000010000000D0000001A
16404 ./000000010000000D0000001D
16404 ./000000010000000D0000001C
16404 ./000000010000000D00000020
16404 ./000000010000000D00000021
16404 ./000000010000000D0000001B
4 ./archive_status
16404 ./000000010000000D00000023
16404 ./000000010000000D0000001F
16404 ./000000010000000D00000018
196856 .

They are all the same size, so it does not look like a truncated
file... Or am i just misinterpreting the error message and its one of
the files elsewhere?

The file system is ext3 and it fscked fine, and nothing is the the
lost+found dir/. As far as i know the computer was allowed to sync
the buffers to disk before the reboot (the plug was not pulled or
anything).

Any Ideas?

Otherwise it sounds like ill just have to chalk this one up to the
gods, and hope its fixed in 8.1.4....

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ian Harding 2006-03-20 19:50:08 Re: Disability the trigger
Previous Message Ted Byers 2006-03-20 16:25:30 Double checking my logic?

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2006-03-20 18:07:03 Re: [HACKERS] PostgreSQL Anniversary Proposals --Important
Previous Message Christian Mair 2006-03-20 17:38:20 Re: [Pgbuildfarm-members] guppie: 64MB RAM too small?