On Monday, February 20, 2012 5:32:01 pm Tom Lane wrote: > Maxim Boguk <maxim.boguk@xxxxxxxxx> 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@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. If I am following correctly that is due to this: "I recreated table from scratch and keep the damaged table under another name (through alter table agency_statistics rename to agency_statistics_old). So I have files to dig into." > > regards, tom lane -- Adrian Klaver adrian.klaver@xxxxxxxxx -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
