From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)postgresql(dot)org, mayank(dot)mittal(dot)1982(at)hotmail(dot)com |
Subject: | Re: BUG #7562: could not read block 0 in file "base/16385/16585": read only 0 of 8192 bytes |
Date: | 2012-09-20 22:10:35 |
Message-ID: | 201209210010.35352.andres@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Thursday, September 20, 2012 11:38:52 PM Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > On Thursday, September 20, 2012 07:15:17 PM Tom Lane wrote:
> >> Hmm. There is a fix for a slave-side-index-corruption problem in 9.1.6,
> >> which is due to be announced Monday. I am not certain whether this is
> >> the same thing though; that bug is low-probability as far as we can
> >> tell (it would only happen if the master had been in the middle of an
> >> index page split or page deletion at the instant of failover). Anyway
> >> the first thing to find out is whether 9.1.6 fixes it.
> >
> > I think the likelihood of that bug causing the the index file to be zero
> > bytes
>
> > - at least thats what I read from $subject - is really, really small:
> Sure, but what about the heap? The case I was speculating about was
> that the heap had been truncated, but because of the corruption problem,
> the index still had heap pointers in it. We don't know what file 16585
> is supposed to be.
Hm. Interesting thought.
*think*
Wouldn't the truncation have created a completely new index relation?
Greetings,
Andres
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-09-20 22:18:12 | Re: BUG #7562: could not read block 0 in file "base/16385/16585": read only 0 of 8192 bytes |
Previous Message | Tom Lane | 2012-09-20 21:38:52 | Re: BUG #7562: could not read block 0 in file "base/16385/16585": read only 0 of 8192 bytes |