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

vacumm error

From: Stefanos Harhalakis <v13(at)it(dot)teithe(dot)gr>
To: pgsql-bugs(at)postgresql(dot)org
Subject: vacumm error
Date: 2002-11-22 20:51:16
Message-ID: 200211222251.16642.v13@it.teithe.gr (view raw or flat)
Thread:
Lists: pgsql-bugs
I'm running postgresql 7.2.1 on linux.

I cannot run vacuumm on a table in a database i'm running for about 7 months.
I get:

ERROR:  No one parent tuple was found

I've found an older posting about that but the poster said that after 
restarting it was fixed. In my case this is not true. I've restarted 
postgresql but it didn't work. Noone else is trying to use this database 
(other databases are used).

test=> vacuum full analyze verbose entities;
NOTICE:  --Relation entities--
NOTICE:  Pages 312833: Changed 107130, reaped 273241, Empty 0, New 0; Tup 
9895954: Vac 9005277, Keep/VTL 0/0, UnUsed 44715182, MinLen 36, MaxLen 36; 
Re-using: Free/Avail. Space 1945751280/1945279044; EndEmpty/Avail. Pages 
0/273480.
        CPU 31.30s/9.81u sec elapsed 138.29 sec.
NOTICE:  Index entities_pkey: Pages 277210; Tuples 9895954: Deleted 9005277.
        CPU 33.33s/75.02u sec elapsed 401.49 sec.
ERROR:  No one parent tuple was found

I had fsync=false in postgresql.conf and the machine crashed but i didn't
notice anything strange since then. I've seen the database to grow up each
day after i did a kill -9 to two db backends. At that time postgre restarted
telling me that the shared memory area is possibly corrupted.

The table entities is an one column table (don't ask why :):

test=# \d entities
                         Table "entities"
 Column |  Type   |                   Modifiers                    
--------+---------+------------------------------------------------
 id     | integer | not null default nextval('seq_entities'::text)
Primary key: entities_pkey
Triggers: RI_ConstraintTrigger_26872259,
          RI_ConstraintTrigger_26872261,
          RI_ConstraintTrigger_26872268,
          RI_ConstraintTrigger_26872270,
          RI_ConstraintTrigger_26872277,
          RI_ConstraintTrigger_26872279,
          RI_ConstraintTrigger_26872286,
          RI_ConstraintTrigger_26872288,
          RI_ConstraintTrigger_26872295,
          RI_ConstraintTrigger_26872297,
          RI_ConstraintTrigger_26872304,
          RI_ConstraintTrigger_26872306,
          RI_ConstraintTrigger_26872313,
          RI_ConstraintTrigger_26872315,
          RI_ConstraintTrigger_26872323,
          RI_ConstraintTrigger_26872325,
          RI_ConstraintTrigger_26872333,
          RI_ConstraintTrigger_26872335,
          RI_ConstraintTrigger_26872343,
          RI_ConstraintTrigger_26872345,
          RI_ConstraintTrigger_26872353,
          RI_ConstraintTrigger_26872355,
          RI_ConstraintTrigger_26872250,
          RI_ConstraintTrigger_26872252,
          RI_ConstraintTrigger_101919110,
          RI_ConstraintTrigger_101919112

I'm currently running vacumm full on another (larger) table 
(table entities has 312K pages and this one has 1.3M pages)

TIA

<<V13>>


Responses

pgsql-bugs by date

Next:From: Philip WarnerDate: 2002-11-23 02:53:47
Subject: Re: Is this planner choice easily explained?
Previous:From: Rafael Villalobos PratsDate: 2002-11-22 17:07:30
Subject: Pgsqlv7.3RC1, pgadminII v 1.4.0 Dropping a field does not drop asociate foreign key

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