Re: BUG #7562: could not read block 0 in file "base/16385/16585": read only 0 of 8192 bytes

On Thursday, September 20, 2012 07:15:17 PM Tom Lane wrote:
> mayank(dot)mittal(dot)1982(at)hotmail(dot)com writes:
> > The following bug has been logged on the website:
> > Bug reference: 7562
> > Logged by: Mayank Mittal
> > Email address: mayank(dot)mittal(dot)1982(at)hotmail(dot)com
> > PostgreSQL version: 9.1.5
> > Operating system: Debian Linux 6.0
> > Description:
> >
> > We are using 2 node set-up of PostgreSQL 9.1.5 in which one is master and
> > other is slave which is in sync of master with streaming replication.
> > The design is in such a way that in case of master node failure the slave
> > node has to take master role. I'm controlling this behaviour using
> > Corosync and Heartbeat.
> > My application is requirement needs heavy database updates. Upon
> > fail-over I've noticed that database indexes got corrupted.
What kind of indexes are you using? Hash indexes by any chance?

As you say downthread the failures are frequent could you provide a bit more
details about your setup (including configuration, initial setup etc) and the
logs on both machines?

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

The index would need to be created (setting a proper BM_PERMANENT flag on the
meta page), evicted from the buffer cache and thus written to the filesystem,
the root page would need to split causing the meta page to be rewritten (this
time without a proper BM_PERMANENT) in a very quick succession followed by a
OS/HW failure loosing the data already in the OS cache.
So, unless I am missing something, I don't see how that can happen.

Greetings,

Andres
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services