Return-Path: owner-postman 
Delivery-Date: Fri, 29 Apr 94 13:41:19 -0700
Return-Path: owner-postman
Received: from localhost (localhost [127.0.0.1]) by nobozo.CS.Berkeley.EDU (8.6.4/8.6.3) with SMTP id KAA29080 for postgres-redist; Fri, 29 Apr 1994 10:22:19 -0700
Resent-From: POSTGRES mailing list <postman@postgres.Berkeley.EDU>
Resent-Message-Id: <199404291722.KAA29080@nobozo.CS.Berkeley.EDU>
Sender: owner-postman@postgres.Berkeley.EDU
X-Return-Path: owner-postman
Received: from faerie.CS.Berkeley.EDU (faerie.CS.Berkeley.EDU [128.32.149.14]) by nobozo.CS.Berkeley.EDU (8.6.4/8.6.3) with ESMTP id KAA29068 for <postgres@postgres.Berkeley.EDU>; Fri, 29 Apr 1994 10:22:19 -0700
Received: from localhost (localhost [127.0.0.1]) by faerie.CS.Berkeley.EDU (8.6.4/8.1B) with SMTP id KAA14113; Fri, 29 Apr 1994 10:22:08 -0700
Message-Id: <199404291722.KAA14113@faerie.CS.Berkeley.EDU>
X-Authentication-Warning: faerie.CS.Berkeley.EDU: Host localhost didn't use HELO protocol
From: aoki@postgres.Berkeley.EDU (Paul M. Aoki)
To: Thilo Gaul <gaul@ira.uka.de>
Cc: postgres@postgres.Berkeley.EDU
Subject: Re: Crashed database? 
Reply-To: aoki@postgres.Berkeley.EDU (Paul M. Aoki)
In-reply-to: Your message of Fri, 29 Apr 94 18:33:22 MET DST 
	     <"iraun1.ira.648:29.04.94.16.33.33"@ira.uka.de> 
Date: Fri, 29 Apr 94 10:22:08 -0700
X-Sender: aoki@postgres.Berkeley.EDU
Resent-To: postgres-redist@postgres.Berkeley.EDU
X-Mts: smtp
Resent-Date: Fri, 29 Apr 94 10:22:19 -0700
Resent-XMts: smtp

Thilo Gaul <gaul@ira.uka.de> writes:
> Query sent to backend is "retrieve (PKT.all) where PKT.x=42 "
> WARN:Apr 29 18:15:37:heap_openr on PKT failed
> other tables don't seem to be corrupted...

if that is the case, this suggests to me that the PKT table
has been "destroy"ed by the "destroy" command.

this message sounds horrifying but it actually just means "i 
couldn't open the file for this table".  (avi pfeffer got tired 
of seeing it and changed it to something more friendly in 4.2.)
a set of crashed catalogs (or catalog indices) tends to fail 
much more spectacularly than that.

test 1:
	retrieve (pg_class.all) where pg_class.relname = "PKT"
test 1a:
	retrieve (pg_class.all) where pg_class.relname ~ "PKT"
test 2:
	ls -l <your postgres directory>/data/base/<your database>/PKT

if both 1 and 2 return nothing then someone ran the "destroy" 
command.  alas.

if 1 returns something but 2 does not, then someone somehow 
dinked your file system (inode got cleared, rm PKT, whatever).
alas, again.

if 2 returns something but 1 does not, you may have lost part of
the class catalog.  if every other table ever created is still
there, then in all likelihood that row in the class table was
somehow accidentally deleted by a user.  far less likely is:
there was an extremely subtle bug (only observed once, fixed in 
4.2) where indices could "lose" tuples.  if 1 returns nothing 
but 1a returns something, you have found this bug (otherwise,
you haven't).

if both 1 and 2 return something then there is something weird 
going on.  if the table is actually corrupted you will generally
be able to scan it but scans will either crash or get weird
answers; i don't know of any failure modes where a call to 
open(2) fails because of corruption of the file *contents*!  in
all likelihood there is a file ownership/permission problem.
--
  Paul M. Aoki  |  CS Div., Dept. of EECS, UCB  |  aoki@postgres.Berkeley.EDU
                |  Berkeley, CA 94720           |  ...!uunet!ucbvax!aoki

===============================================================================
    To add/remove yourself from the POSTGRES mailing list: send mail with 
    the subject line ADD or DEL to "postgres-request@postgres.Berkeley.EDU"

    If this fails, send mail to "post_questions@postgres.Berkeley.EDU" and
    a human will deal with it.  DO NOT post to the "postgres" mailing list.
===============================================================================