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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-bugs by date

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