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
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 |