Re: FATAL: index contains unexpected zero page at block

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dmitriy Tyugaev <dtyugaev(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: FATAL: index contains unexpected zero page at block
Date: 2012-11-14 22:50:39
Message-ID: 28041.1352933439@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Dmitriy Tyugaev <dtyugaev(at)gmail(dot)com> writes:
> Nov 14 18:24:04 uno postgres84[24208]: [6-1] user=,db= LOG: redo done at
> 237B/90A1DF98
> Nov 14 18:24:04 uno postgres84[24208]: [7-1] user=,db= LOG: last completed
> transaction was at log time 2012-11-10 10:26:28.484922+04
> Nov 14 18:24:04 uno postgres84[24208]: [8-1] user=,db= FATAL: index
> "316879235" contains unexpected zero page at block 264
> Nov 14 18:24:04 uno postgres84[24208]: [8-2] user=,db= HINT: Please
> REINDEX it.

Hm. Apparently it's hitting the zero page while trying to clean up an
incomplete index page split after reaching the end of WAL. This is not
good --- it means your filesystem failed to retain data that it claimed
had been written to disk safely. You should look into fsync-related
system settings after you get out of the immediate problem.

As far as getting out of the immediate problem is concerned, I think
you have little option except to use pg_resetxlog. This will mean
the loss of whatever actions it was trying to replay, which may well
mean that you end up with data corruption (not just index corruption).
I'd suggest a dump and reload after you get the server to start.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2012-11-14 23:04:12 Re: How do query optimizers affect window functions
Previous Message Jeff Janes 2012-11-14 22:38:46 Re: How do query optimizers affect window functions