| From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
|---|---|
| To: | Nikhil Sontakke <nikhil(dot)sontakke(at)enterprisedb(dot)com> |
| Cc: | Greg Stark <gsstark(at)mit(dot)edu>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Fwd: index corruption in PG 8.3.13 |
| Date: | 2011-03-16 13:26:29 |
| Message-ID: | 1300281862-sup-4259@alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Excerpts from Nikhil Sontakke's message of mié mar 16 08:51:00 -0300 2011:
> Hi,
>
> > To summarize, as I see it - the zeroed out block 523 should have been
> > the second left-most leaf and should have pointed out to 522. Thus
> > re-establishing the index chain
> >
> > 524 -> 523 -> 522 -> 277 -> ...
> >
> >> Was there a machine restart in the picture as well?
> >
>
> It seems there might have been a machine restart involved too. So I
> guess even WAL writing could have been impacted.
Maybe the filesystem decided to fill a couple of FS pages (one PG page)
with zeroes on recovery due to believing that it wasn't fsynced at the
time of the crash.
--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2011-03-16 14:27:37 | Re: Re: [COMMITTERS] pgsql: Basic Recovery Control functions for use in Hot Standby. Pause, |
| Previous Message | Nikhil Sontakke | 2011-03-16 12:27:31 | Re: Fwd: index corruption in PG 8.3.13 |