Hi Adrian,
Thanks Adrian for you quick reply. I am looking in this that why db came into this stage.
--I have found overheating servers to be particularly prone to index corruption and if indexes can get corrupt one has
toworry about data becoming ---corrupt too.
Is the above statement true?
What is the meaming of toasted values?
What is this pg_toast? Can you please share any link on this?
Note from the shared link
--------------------------------------
Given that what you did was a reindex, what probably happened was it used an index scan to try to locate the toasted
valuesin the table and couldnt find one. This sounds like a corrupted index. Vacuum analyse does alter the table but
reindexdoes not and the changes are very minor.
The way to think about this is that TOASTed attributes are actually broken into chunks of about 4k in size and these
arestored in rows. They are looked up and sorted/reconnected with the main row at query time. It sounds like an index
usedhere was corrupted and so the reindex solved the problem.
I have found corrupted indexes are usually a sign that something is not well with the server. It is good to check and
makesure memory, CPU's and hard drives are all happy and not reporting problems. I have found overheating servers to be
particularlyprone to index corruption and if indexes can get corrupt one has to worry about data becoming corrupt too.
Regards
Tarkeshwar
-----Original Message-----
From: Adrian Klaver [mailto:adrian.klaver@aklaver.com]
Sent: 03 December 2014 20:22
To: M Tarkeshwar Rao; pgsql-general@postgresql.org
Subject: Re: [GENERAL] FW: getting error while running sql on mm_activealrm table
On 12/03/2014 03:07 AM, M Tarkeshwar Rao wrote:
> Hi all,
>
> We are getting following error message on doing any action on the
> table like(Select or open from pgadmin).
>
> Please suggest.
>
http://dba.stackexchange.com/questions/31008/pg-dump-and-error-missing-chunk-number-0-for-toast-value
Though the question still remains, what got it into that state?
Any recent hardware/software issues?
>
> Regards
>
> Tarkeshwar
>
--
Adrian Klaver
adrian.klaver@aklaver.com