Re: BUG #7562: could not read block 0 in file "base/16385/16585": read only 0 of 8192 bytes
От | Mayank Mittal |
---|---|
Тема | Re: BUG #7562: could not read block 0 in file "base/16385/16585": read only 0 of 8192 bytes |
Дата | |
Msg-id | COL002-W8969D3ED20672EDE4550E9D5990@phx.gbl обсуждение исходный текст |
Ответ на | Re: BUG #7562: could not read block 0 in file "base/16385/16585": read only 0 of 8192 bytes (Andres Freund <andres@2ndquadrant.com>) |
Список | pgsql-bugs |
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 =
В списке pgsql-bugs по дате отправления: