Skip site navigation (1) Skip section navigation (2)

Corrupted db?

From: Michael Brusser <michael(at)synchronicity(dot)com>
To: Pgsql-Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Corrupted db?
Date: 2004-01-26 12:42:19
Message-ID: DEEIJKLFNJGBEMBLBAHCEEMAECAA.michael@synchronicity.com (view raw or flat)
Thread:
Lists: pgsql-hackers
We got a problem ticket from the customer.
Messages in the error_log indicated problem trying to insert
a duplicate value into a table.
 
Looking at the database (v.7.3.2 on Solaris) I'm puzzled with this:

syncdb=# \d
ERROR:  Cache lookup failed for relation 17075

syncdb=# \di
ERROR:  Cache lookup failed for relation 17081

syncdb=# \d property_types;
ERROR:  Cache lookup failed for relation 17075

syncdb=# \d public.property_types
           Table "public.property_types"
   Column    |          Type           | Modifiers 
-------------+-------------------------+-----------
 id          | integer                 | not null
 name        | character varying(256)  | not null
 stamp       | date                    | not null
 description | character varying(1024) | 
Indexes: pt_pk primary key btree (id),
         pt_name_uid_uk unique btree (name)


syncdb=# SET search_path = public, pg_catalog;
SET
syncdb=# \d property_types;
ERROR:  Cache lookup failed for relation 17075

syncdb=# select * from pg_namespace ;
  nspname   | nspowner | nspacl 
------------+----------+--------
 pg_catalog |        1 | {=U}
 pg_toast   |        1 | {=}
 public     |        1 | {=UC}
 pg_temp_1  |        1 | 
(4 rows)

syncdb=# select * from property_types;
 id | name | stamp | description 
----+------+-------+-------------
(0 rows)

INSERT INTO property_types (id, name, description, stamp)
VALUES (nextval('pt_seq'), 'FROM_RELATIONSHIP', 
       'Describes the relationship of ...', date('today'));

ERROR:  Cannot insert a duplicate key into unique index pt_name_uid_uk
---------------------------------------------

I can only guess that something is corrupted.
What could lead to that?
Can this can be prevented or repaired?

Thank you,
Mike.



Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2004-01-26 12:55:20
Subject: Re: cache control?
Previous:From: Christopher Kings-LynneDate: 2004-01-26 09:04:09
Subject: Re: Disaster!

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group