Thread: ERROR: cannot read block 15157 of hp_tran: Success
Please help
Please bear with us we are in process of upgrade but many servers are still using version 7.3.4 of PostgreSQL running on RedHat5
A certain table seems to be corrupt when trying to select everything from this table, it throws out an error. See the error below
db0303=# SELECT count(*) from hp_tran;
ERROR: cannot read block 15157 of hp_tran: Success
db0303=#
There is no problem with the disc
Please assist, I am a Juniour DBA,
Confidentiality Notice:http://ucs.co.za/conf.html
The contents of and attachments to this e-mail are intended for the addressee only, and may contain the confidential information of UCS Group and/or its subsidiaries. Any review, use or dissemination thereof by anyone other than the intended addressee is prohibited. If you are not the intended addressee please notify the writer immediately and destroy the e-mail. UCS Group Limited and its subsidiaries distance themselves from and accept no liability for unauthorised use of their e-mail facilities or e-mails sent other than strictly for business purposes.
Khangelani Gama <Khangelani.Gama@ucs-software.co.za> writes: > Please bear with us we are in process of upgrade but many servers are still using version 7.3.4 of PostgreSQL running onRedHat5 Egad... > A certain table seems to be corrupt when trying to select everything from this table, it throws out an error. See the errorbelow > db0303=# SELECT count(*) from hp_tran; > ERROR: cannot read block 15157 of hp_tran: Success This probably indicates that the table has been truncated in mid-block, ie the file isn't a multiple of 8K long. Recent versions of PG would give you a message that made that clearer, but I don't think 7.3 will. You could try using dd to pad the file out to the next 8K boundary (with zeroes), but I expect you'll find that the data on that page is trashed and you'll have to truncate it away instead in order to not get errors. > There is no problem with the disc If the underlying OS is as unmaintained as the database is, you might well be encountering kernel bugs :-( regards, tom lane
Thanks Tom ..but could you please supply with an example on how I should pad the file using dd? -----Original Message----- From: pgsql-admin-owner@postgresql.org [mailto:pgsql-admin-owner@postgresql.org] On Behalf Of Tom Lane Sent: Thursday, April 15, 2010 7:55 PM To: Khangelani Gama Cc: pgsql-admin@postgresql.org Subject: Re: [ADMIN] ERROR: cannot read block 15157 of hp_tran: Success Khangelani Gama <Khangelani.Gama@ucs-software.co.za> writes: > Please bear with us we are in process of upgrade but many servers are still using version 7.3.4 of PostgreSQL running onRedHat5 Egad... > A certain table seems to be corrupt when trying to select everything from this table, it throws out an error. See the errorbelow > db0303=# SELECT count(*) from hp_tran; > ERROR: cannot read block 15157 of hp_tran: Success This probably indicates that the table has been truncated in mid-block, ie the file isn't a multiple of 8K long. Recent versions of PG would give you a message that made that clearer, but I don't think 7.3 will. You could try using dd to pad the file out to the next 8K boundary (with zeroes), but I expect you'll find that the data on that page is trashed and you'll have to truncate it away instead in order to not get errors. > There is no problem with the disc If the underlying OS is as unmaintained as the database is, you might well be encountering kernel bugs :-( regards, tom lane -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin The contents of and attachments to this e-mail are intended for the addressee only, and may contain the confidential informationof UCS Group and/or its subsidiaries. Any review, use or dissemination thereof by anyone other than the intendedaddressee is prohibited. If you are not the intended addressee please notify the writer immediately and destroythe e-mail. UCS Group Limited and its subsidiaries distance themselves from and accept no liability for unauthoriseduse of their e-mail facilities or e-mails sent other than strictly for business purposes.