On 12/03/2014 09:30 PM, M Tarkeshwar Rao wrote:
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 to worry about data becoming ---corrupt
too.
Is the above statement true?
All I can say is that equipment is designed to run in a range of
temperatures. The temperature goes outside that range and the chance
increases that something will go wrong. Whether that affects indexes
more is not something I could say.
What is the meaming of toasted values?
What is this pg_toast? Can you please share any link on this?
http://www.postgresql.org/docs/9.3/static/storage-toast.html
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 values in the table and couldnt find
one. This sounds like a corrupted index. Vacuum analyse does alter the table
but reindex does 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 are stored in rows. They are looked up and
sorted/reconnected with the main row at query time. It sounds like an index
used here 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 make sure memory, CPU's and hard
drives are all happy and not reporting problems. I have found overheating
servers to be particularly prone to index corruption and if indexes can get
corrupt one has to worry about data becoming corrupt too.
Regards
Tarkeshwar
--
Adrian Klaver
adrian.kla...@aklaver.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
