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 01:32:01 |
Message-ID: | 21084.1329787921@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:
> One of servers under my support 2 days ago produced the next error:
> ERROR: could not read block 135 in file "base/16404/118881486": read only
> 0 of 8192 bytes
> ...
> What I see in file system:
> hh=# SELECT relfilenode from pg_class where relname='agency_statistics_old';
> relfilenode
> -------------
> 118881486
> postgres(at)db10:~/tmp$ ls -la
> /var/lib/postgresql/9.0/main/base/16404/118881486
> -rw------- 1 postgres postgres 0 2012-02-20 12:04
> /var/lib/postgresql/9.0/main/base/16404/118881486
> So table file size zero bytes (seems autovacuum truncated that table to 0
> bytes).
Hmmm .... something did, but I see no clear evidence that it was
autovacuum.
Do you know why the mod date on the file is 2012-02-20 12:04? That's
more than two days after the error in your logs, so it's not clear to me
that the current state of the file tells us much about what happened on
the 17th. If autovacuum had truncated the table then, and the table
wasn't touched otherwise, the file mod date shouldn't have increased.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2012-02-21 01:37:09 | Re: Unfamous 'could not read block ... in file "...": read only 0 of 8192 bytes' again |
Previous Message | Maxim Boguk | 2012-02-21 00:10:09 | Unfamous 'could not read block ... in file "...": read only 0 of 8192 bytes' again |
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2012-02-21 01:37:09 | Re: Unfamous 'could not read block ... in file "...": read only 0 of 8192 bytes' again |
Previous Message | Peter Geoghegan | 2012-02-21 01:19:55 | Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation) |