No, Most of the time I've seen in block 0, but 2-3 time it was with other blocks as well.
Regards, Mayank MittalBarco Electronics System Ltd.Mob. +91 9873437922 > From: and...@2ndquadrant.com > To: maili...@oopsware.de > Subject: Re: [BUGS] BUG #7562: could not read block 0 in file > "base/16385/16585": read only 0 of 8192 bytes > Date: Fri, 21 Sep 2012 10:25:50 +0200 > CC: t...@sss.pgh.pa.us; pgsql-bugs@postgresql.org; > mayank.mittal.1...@hotmail.com > > On Friday, September 21, 2012 10:18:39 AM Bernd Helmle wrote: > > --On 20. September 2012 18:18:12 -0400 Tom Lane <t...@sss.pgh.pa.us> wrote: > > > If it were an actual TRUNCATE, yeah. But it could be a case of VACUUM > > > truncating a now-empty table to zero blocks. > > > > > > But nothing like this would explain the OP's report that corruption is > > > completely reproducible for him. So I like your theory about hash index > > > use better. We really oughta get some WAL support in there. > > > > We had a similar issue at a customer site. The server was shut down for > > updating it from 9.1.4 to 9.1.5, after starting it again the log was > > immediately cluttered with > How was it shutdown? -m fast or -m immediate? > > > ERROR: could not read block 251 in file "base/6447890/7843708": read only > > 0 of 8192 bytes > So, not block 0. How many blocks does the new index contain? > > Mayank: > Do you always see the error in block 0? > > > The index was a primary key on table with mostly INSERTS (only a few > > hundred DELETEs, autovacuum didn't even bother to vacuum it yet and no > > manual VACUUM). According to the customer, no DDL action takes place on > > this specific table. The kernel didn't show any errors. > Ok, this is getting wierd. Bernd some minutes ago confirmed on IRC that the > table is older than the last checkpoint... > > 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