Received: from maia.hub.org (maia-2.hub.org [200.46.204.251])
	by mail.postgresql.org (Postfix) with ESMTP id 0F86CB5DBFA
	for <pgsql-admin-postgresql.org@mail.postgresql.org>;
	Fri, 26 Aug 2011 01:14:49 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia,
	port 10024) with ESMTP id 15716-01 for
	<pgsql-admin-postgresql.org@mail.postgresql.org>;
	Fri, 26 Aug 2011 04:14:42 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-vx0-f174.google.com (mail-vx0-f174.google.com
	[209.85.220.174])
	by mail.postgresql.org (Postfix) with ESMTP id 84EBBB5DBF9
	for <pgsql-admin@postgresql.org>; Fri, 26 Aug 2011 01:14:42 -0300 (ADT)
Received: by vxi9 with SMTP id 9so2286987vxi.19
	for <pgsql-admin@postgresql.org>; Thu, 25 Aug 2011 21:14:41 -0700 (PDT)
Received: by 10.52.74.197 with SMTP id w5mr642137vdv.233.1314332081763;
	Thu, 25 Aug 2011 21:14:41 -0700 (PDT)
Received: from [10.1.1.7] (124-169-228-164.dyn.iinet.net.au [124.169.228.164])
	by mx.google.com with ESMTPS id o7sm20120vcv.10.2011.08.25.21.14.39
	(version=SSLv3 cipher=OTHER); Thu, 25 Aug 2011 21:14:41 -0700 (PDT)
Message-ID: <4E571DA1.9000206@ringerc.id.au>
Date: Fri, 26 Aug 2011 12:14:25 +0800
From: Craig Ringer <ringerc@ringerc.id.au>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:6.0) Gecko/20110812 Thunderbird/6.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>
	<4E4E0573.2010508@ringerc.id.au>
	<1313939235.83661.YahooMailNeo@web120005.mail.ne1.yahoo.com>
In-Reply-To: <1313939235.83661.YahooMailNeo@web120005.mail.ne1.yahoo.com>
Content-Type: multipart/alternative;
	boundary="------------070304070209070208040602"
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/206
X-Sequence-Number: 38193

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

On 21/08/2011 11:07 PM, A J wrote:
> So I assume there is no redundant information stored such as checksum 
> to validate the files against the stored checksums.

Nope, there are no checksums.

It's the storage subsystem's job to make sure it doesn't mangle data on 
disk and reads the data as it was written. It's the OS's job to make 
sure nobody else overwrites or messes with that data while it's in RAM 
cache or on disk.

Index corruption means you've hit a hardware fault, OS bug, or possibly 
a PostgreSQL bug.

Only some kinds of corruption could be detected by application-level 
checksums. If the OS or storage subsystem just failed to write a page, 
Pg wouldn't be able to tell, for example. Checksums _would_ detect split 
page writes, single-bit faults, corrupted disk sectors and the like and 
could potentially be useful.

> I don't have an active issue. Just trying to understand in detail how 
> Postgres behaves under index corruption.

Like most forms of fault behaviour, it is undefined in the "C standard" 
sense of the meaning, though perhaps not quite as willing to just eat 
data ;-)

--
Craig Ringer

--------------070304070209070208040602
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 21/08/2011 11:07 PM, A J wrote:
    <blockquote
      cite="mid:1313939235.83661.YahooMailNeo@web120005.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><span>So I assume there is no redundant information stored
            such as checksum to validate the files against the stored
            checksums.</span></div>
      </div>
    </blockquote>
    <br>
    Nope, there are no checksums.<br>
    <br>
    It's the storage subsystem's job to make sure it doesn't mangle data
    on disk and reads the data as it was written. It's the OS's job to
    make sure nobody else overwrites or messes with that data while it's
    in RAM cache or on disk.<br>
    <br>
    Index corruption means you've hit a hardware fault, OS bug, or
    possibly a PostgreSQL bug.<br>
    <br>
    Only some kinds of corruption could be detected by application-level
    checksums. If the OS or storage subsystem just failed to write a
    page, Pg wouldn't be able to tell, for example. Checksums _would_
    detect split page writes, single-bit faults, corrupted disk sectors
    and the like and could potentially be useful. <br>
    <br>
    <blockquote
      cite="mid:1313939235.83661.YahooMailNeo@web120005.mail.ne1.yahoo.com"
      type="cite">
      <div style="color:#000; background-color:#fff; font-family:times
        new roman, new york, times, serif;font-size:12pt">
        <div><span>I don't have an active issue. Just trying to
            understand in detail how Postgres behaves under index
            corruption.</span><br>
        </div>
      </div>
    </blockquote>
    <br>
    Like most forms of fault behaviour, it is undefined in the "C
    standard" sense of the meaning, though perhaps not quite as willing
    to just eat data ;-)<br>
    <br>
    --<br>
    Craig Ringer<br>
  </body>
</html>

--------------070304070209070208040602--