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