No=2C Most of the time I've seen in block 0=2C but 2-3 time it was with oth=
er blocks as well.
Regards=2C
Mayank MittalBarco Electronics System Ltd.Mob. +91 9873437922
> From: andres@2ndquadrant.com
> To: mailings@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=2C 21 Sep 2012 10:25:50 +0200
> CC: tgl@sss.pgh.pa.us=3B pgsql-bugs@postgresql.org=3B mayank.mittal.1982@=
hotmail.com
>=20
> On Friday=2C September 21=2C 2012 10:18:39 AM Bernd Helmle wrote:
> > --On 20. September 2012 18:18:12 -0400 Tom Lane <tgl@sss.pgh.pa.us> wro=
te:
> > > If it were an actual TRUNCATE=2C yeah. But it could be a case of VAC=
UUM
> > > truncating a now-empty table to zero blocks.
> > >=20
> > > But nothing like this would explain the OP's report that corruption i=
s
> > > completely reproducible for him. So I like your theory about hash in=
dex
> > > use better. We really oughta get some WAL support in there.
> >=20
> > 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=2C after starting it again the log was
> > immediately cluttered with
> How was it shutdown? -m fast or -m immediate?
>=20
> > ERROR: could not read block 251 in file "base/6447890/7843708": read o=
nly
> > 0 of 8192 bytes
> So=2C not block 0. How many blocks does the new index contain?
>=20
> Mayank:
> Do you always see the error in block 0?
>=20
> > The index was a primary key on table with mostly INSERTS (only a few
> > hundred DELETEs=2C autovacuum didn't even bother to vacuum it yet and n=
o
> > manual VACUUM). According to the customer=2C no DDL action takes place =
on
> > this specific table. The kernel didn't show any errors.
> Ok=2C this is getting wierd. Bernd some minutes ago confirmed on IRC that=
the=20
> table is older than the last checkpoint...
>=20
> Greetings=2C
>=20
> Andres
> --=20
> Andres Freund http://www.2ndQuadrant.com/
> PostgreSQL Development=2C 24x7 Support=2C Training & Services
>=20
>=20
> --=20
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
=
