Re: could not read block 77 of relation 1663/16385/388818775

Lists: pgsql-bugs
From: Darren Reed <darrenr+postgres(at)fastmail(dot)net>
To: pgsql-bugs(at)postgresql(dot)org, an(at)clickware(dot)de
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, craig(at)postnewspapers(dot)com(dot)au
Subject: Re: could not read block 77 of relation 1663/16385/388818775
Date: 2009-02-22 11:29:54
Message-ID: 49A13732.6030704@fastmail.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-bugs

As another data point, I upgraded from 8.2.6 to 8.3.6
and I saw those corruption messages after restoring
pg_dump files back into the database with psql and
inserting a bunch of data (some duplicate records
got rejected.) The insertion of new data is via
perl's DBI interface.

This was after the upgrade, so there had been no
dirty stops, etc.

Thinking that it might be an index problem, I've tried
reindexing the entire database - no errors but neither
does the problem go away. Nor does it stop the database
from starting up.

Where it pops up seems to be random (going from the errors
on postgres's log from earlier starts.) At the moment,
it's stopping me from creating a new table or dropping an
existing table (where I first ran into the error.) But
accessing all of the tables is fine...

I suppose the logical thing for me to do is go back to 8.2.6.

Darren

ERROR: could not read block 1 of relation 1664/0/1233: read only 0 of
8192 bytes


From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: Darren Reed <darrenr+postgres(at)fastmail(dot)net>
Cc: pgsql-bugs(at)postgresql(dot)org, an(at)clickware(dot)de, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, craig(at)postnewspapers(dot)com(dot)au
Subject: Re: could not read block 77 of relation 1663/16385/388818775
Date: 2009-02-22 14:41:36
Message-ID: 87mycev8in.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-bugs


Darren Reed <darrenr+postgres(at)fastmail(dot)net> writes:

> ERROR: could not read block 1 of relation 1664/0/1233: read only 0 of
> 8192 bytes

FWIW this is pg_shdepend_reference_index which is actually a bit special. It's
a "shared" relation which means it spans all your databases. Your reindex
didn't rebuild to. To reindex it you would have to shut down postgres and run
REINDEX in postgres in "standalone" mode.

> I suppose the logical thing for me to do is go back to 8.2.6.

I think it would be more interesting to know how you got into this situation.
When you ran initdb did anything unusual happen? Is it possible anything later
truncated these files?

There's no reason I can imagine 8.3 would be any more susceptible to this than
8.2. And certainly no reason you would want to use a year-old release of 8.2
missing a year's worth of bug fixes and security fixes. The current release of
8.2 is 8.2.12.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!


From: Darren Reed <darrenr+postgres(at)fastmail(dot)net>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org, an(at)clickware(dot)de, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, craig(at)postnewspapers(dot)com(dot)au
Subject: Re: could not read block 77 of relation 1663/16385/388818775
Date: 2009-02-22 22:49:56
Message-ID: 49A1D694.9020904@fastmail.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-bugs

Gregory Stark wrote:
> Darren Reed <darrenr+postgres(at)fastmail(dot)net> writes:
>
>
>> ERROR: could not read block 1 of relation 1664/0/1233: read only 0 of
>> 8192 bytes
>>
>
> FWIW this is pg_shdepend_reference_index which is actually a bit special. It's
> a "shared" relation which means it spans all your databases. Your reindex
> didn't rebuild to. To reindex it you would have to shut down postgres and run
> REINDEX in postgres in "standalone" mode.
>
>
>> I suppose the logical thing for me to do is go back to 8.2.6.
>>
>
> I think it would be more interesting to know how you got into this situation.
> When you ran initdb did anything unusual happen? Is it possible anything later
> truncated these files?
>

Nope.
For me it has been very reproducible:
- init the database
- restore tables from dump files
- create indexes for those tables
- insert some records using perl DBI
- receive above error message

My current logifile goes like this:
- database startup
- create tables creating implicit keys
- lots of checkpoints happening too quick (restores)
- 3 insert errors due to syntax
- 2 EOFs from clients
- ERROR could not read block 1 of relation...

I haven't even run any queries.

The single-user mode REINDEX did fix it, thanks.

Darren


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Darren Reed <darrenr+postgres(at)fastmail(dot)net>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, pgsql-bugs(at)postgresql(dot)org, an(at)clickware(dot)de, craig(at)postnewspapers(dot)com(dot)au
Subject: Re: could not read block 77 of relation 1663/16385/388818775
Date: 2009-02-22 23:03:01
Message-ID: 15188.1235343781@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-bugs

Darren Reed <darrenr+postgres(at)fastmail(dot)net> writes:
> For me it has been very reproducible:

If you can put together a self-contained test case that would let
someone else reproduce it, we'd be very interested to take a look.

regards, tom lane