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

Hello Andres,I didn't mention hashing type for indexes explicitly. I'm relying on the default one which is B-Tree.Here is the basic configuration of my system.
Operating System: Debian Linux 6.0Type: 64-bitFile system Type: ext4RAM : 4G
Also I didn't understand where to find BM_PERMANENT flag setting.
Here is steps for initial setup.
1. Server 1 is running in master mode.2. When server 2 came up. Our Resource Agent initiates pg_dump on master node and copy the dump to data folder of slave node.3. Once copied completely, we create recovery.conf file on the slave node and starts the Postgre.4. In case of Master failure, RA creates trigger file in slave to promote it to master.
I'm using following command to take dump of master:pg_basebackup -U postgres -h <master_node_ip> -P -x -D <backup_location>

Regards,
Mayank MittalBarco Electronics System Ltd.Mob. +91 9873437922

> From: andres(at)2ndquadrant(dot)com
> To: pgsql-bugs(at)postgresql(dot)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(at)sss(dot)pgh(dot)pa(dot)us; mayank(dot)mittal(dot)1982(at)hotmail(dot)com
>
> 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
>
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs