Received: from maia.hub.org (maia-3.hub.org [200.46.204.243])
	by mail.postgresql.org (Postfix) with ESMTP id B2035B5DBC4
	for <pgsql-admin-postgresql.org@mail.postgresql.org>;
	Fri, 19 Aug 2011 03:41:10 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia,
	port 10024) with ESMTP id 41348-06 for
	<pgsql-admin-postgresql.org@mail.postgresql.org>;
	Fri, 19 Aug 2011 06:41:04 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-qw0-f46.google.com (mail-qw0-f46.google.com
	[209.85.216.46])
	by mail.postgresql.org (Postfix) with ESMTP id B710FB5D80A
	for <pgsql-admin@postgresql.org>; Fri, 19 Aug 2011 03:41:01 -0300 (ADT)
Received: by qwk3 with SMTP id 3so1883515qwk.19
	for <pgsql-admin@postgresql.org>; Thu, 18 Aug 2011 23:41:01 -0700 (PDT)
Received: by 10.224.17.131 with SMTP id s3mr1481416qaa.393.1313736060980;
	Thu, 18 Aug 2011 23:41:00 -0700 (PDT)
Received: from [10.1.1.8] (124-169-181-228.dyn.iinet.net.au [124.169.181.228])
	by mx.google.com with ESMTPS id
	cg10sm1166294qab.0.2011.08.18.23.40.58 (version=SSLv3 cipher=OTHER);
	Thu, 18 Aug 2011 23:41:00 -0700 (PDT)
Message-ID: <4E4E0573.2010508@ringerc.id.au>
Date: Fri, 19 Aug 2011 14:40:51 +0800
From: Craig Ringer <ringerc@ringerc.id.au>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: A J <s5aly@yahoo.com>
CC: PG Admin <pgsql-admin@postgresql.org>
Subject: Re: Question on Postgres Index internals
References: <1313703964.54877.YahooMailNeo@web120001.mail.ne1.yahoo.com>
In-Reply-To: <1313703964.54877.YahooMailNeo@web120001.mail.ne1.yahoo.com>
Content-Type: multipart/alternative;
	boundary="------------000604090000080104060902"
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-1.899 tagged_above=-10 required=5
	tests=BAYES_00=-1.9, HTML_MESSAGE=0.001
X-Spam-Level: 
X-Archive-Number: 201108/176
X-Sequence-Number: 38163

This is a multi-part message in MIME format.
--------------000604090000080104060902
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 19/08/2011 5:46 AM, A J wrote:
> How does Postgres detect corruption of index data files ?
If their structure doesn't make sense, they're corrupt. It doesn't 
actively seek or detect corruption, because it shouldn't happen, and 
cannot be reliably discovered if it has.
> What is the exact mechanism by which it knows that the index is corrupt ?
Numerous different ways, depending on the nature of the damage and the 
type of index. Often it won't know the index is damaged at all.
> Can it happen that part of the index is corrupt but Postgres does not 
> realize because those specific rows are not accessed (but other rows 
> from that table are accessed)
>
Yes, that is possible. It is also possible that a damaged index could 
cause issues like multiple instances of a value that's supposed to be 
unique, or a foreign key reference to a non-existent tuple.

Index corruption should not happen. If you are facing index corruption, 
either you have a hardware problem or you've hit a bug. The vast 
majority of cases are hardware faults.

Perhaps it'd help if you'd supply a little more detail about the 
background. Why you're asking this, and why you (presumably) suspect you 
have index corruption.

--
Craig  Ringer

--------------000604090000080104060902
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 19/08/2011 5:46 AM, A J wrote:
    <blockquote
      cite="mid:1313703964.54877.YahooMailNeo@web120001.mail.ne1.yahoo.com"
      type="cite">
      <div style="color: rgb(0, 0, 0); background-color: rgb(255, 255,
        255); font-family: times new roman,new york,times,serif;
        font-size: 12pt;">
        <div>How does Postgres detect corruption of index data files ?</div>
      </div>
    </blockquote>
    If their structure doesn't make sense, they're corrupt. It doesn't
    actively seek or detect corruption, because it shouldn't happen, and
    cannot be reliably discovered if it has.<br>
    <blockquote
      cite="mid:1313703964.54877.YahooMailNeo@web120001.mail.ne1.yahoo.com"
      type="cite">
      <div style="color: rgb(0, 0, 0); background-color: rgb(255, 255,
        255); font-family: times new roman,new york,times,serif;
        font-size: 12pt;">
        <div> What is the exact mechanism by which it knows that the
          index is corrupt ?</div>
      </div>
    </blockquote>
    Numerous different ways, depending on the nature of the damage and
    the type of index. Often it won't know the index is damaged at all.<br>
    <blockquote
      cite="mid:1313703964.54877.YahooMailNeo@web120001.mail.ne1.yahoo.com"
      type="cite">
      <div style="color: rgb(0, 0, 0); background-color: rgb(255, 255,
        255); font-family: times new roman,new york,times,serif;
        font-size: 12pt;">
        <div> Can it happen that part of the index is corrupt but
          Postgres does not realize because those specific rows are not
          accessed (but other rows from that table are accessed)</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    Yes, that is possible. It is also possible that a damaged index
    could cause issues like multiple instances of a value that's
    supposed to be unique, or a foreign key reference to a non-existent
    tuple.<br>
    <br>
    Index corruption should not happen. If you are facing index
    corruption, either you have a hardware problem or you've hit a bug.
    The vast majority of cases are hardware faults.<br>
    <br>
    Perhaps it'd help if you'd supply a little more detail about the
    background. Why you're asking this, and why you (presumably) suspect
    you have index corruption.<br>
    <br>
    --<br>
    Craig&nbsp; Ringer<br>
  </body>
</html>

--------------000604090000080104060902--