agora inbox for postgres@postgres.berkeley.edu  

help / color / mirror / Atom feed

From: Paul M. Aoki <aoki@postgres.Berkeley.EDU>
To: Thilo Gaul <gaul@ira.uka.de>
Cc: postgres@postgres.Berkeley.EDU
Subject: Re: Crashed database?
Date: Fri, 29 Apr 94 10:22:08 -0700
Message-ID: <199404291722.KAA14113@faerie.CS.Berkeley.EDU> (raw)
In-Reply-To: <"iraun1.ira.648:29.04.94.16.33.33"@ira.uka.de>

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.
===============================================================================

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: postgres@postgres.berkeley.edu
  Cc: aoki@postgres.Berkeley.EDU, gaul@ira.uka.de
  Subject: Re: Crashed database?
  In-Reply-To: <199404291722.KAA14113@faerie.CS.Berkeley.EDU>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox