Re: Unfamous 'could not read block ... in file "...": read only 0 of 8192 bytes' again

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Maxim Boguk <maxim(dot)boguk(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Unfamous 'could not read block ... in file "...": read only 0 of 8192 bytes' again
Date: 2012-02-21 05:03:11
Message-ID: 1407.1329800591@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Maxim Boguk <maxim(dot)boguk(at)gmail(dot)com> writes:
> There is some funny results:

> hh=# VACUUM verbose agency_statistics_old;
> INFO: vacuuming "public.agency_statistics_old"
> INFO: index "agency_statistics_pkey" now contains 0 row versions in 605
> pages
> DETAIL: 0 index row versions were removed.

Wow. That seems to blow my theory to small pieces. If the index
contains no entries then it shouldn't be causing any uniqueness check
probes. But at the same time, if the index is empty then how come
pgstatindex showed avg_leaf_density = 0.45 ?

> May be I should use pageinspect addon to see an actual index pages content?

That or pg_filedump would be interesting. But your experiments with
adding data from the other table will probably have produced some new
index entries, which will confuse the situation. Did you save a
physical copy of the index before that?

Another idea is to attach to the backend with gdb, set a breakpoint at
errfinish, and get a stack trace from the point of the "could not read
block" error. That would show definitively if this is coming from a
uniqueness check or something else entirely.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Maxim Boguk 2012-02-21 05:40:30 Re: Unfamous 'could not read block ... in file "...": read only 0 of 8192 bytes' again
Previous Message Maxim Boguk 2012-02-21 04:50:57 Re: Unfamous 'could not read block ... in file "...": read only 0 of 8192 bytes' again

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2012-02-21 05:11:35 Re: Speed dblink using alternate libpq tuple storage
Previous Message Maxim Boguk 2012-02-21 04:50:57 Re: Unfamous 'could not read block ... in file "...": read only 0 of 8192 bytes' again