Barco Electronics System Ltd.
Mob. +91 9873437922
> From: andres@2ndquadrant.com
> To: pgsql-bugs@postgresql.org
> Subject: Re: [BUGS] BUG #7562: could not read block 0 in file "base/16385/16585": read only 0 of 8192 bytes
> Date: Thu, 20 Sep 2012 23:31:35 +0200
> CC: tgl@sss.pgh.pa.us; mayank.mittal.1982@hotmail.com
>
> On Thursday, September 20, 2012 07:15:17 PM Tom Lane wrote:
> > mayank.mittal.1982@hotmail.com writes:
> > > The following bug has been logged on the website:
> > > Bug reference: 7562
> > > Logged by: Mayank Mittal
> > > Email address: mayank.mittal.1982@hotmail.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
>
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
