Обсуждение: Why my vacuum fails?
Greetings,
I'm trying to do a vacuum and it's not working very well. Could you
please tell me what can I do?
The main problems appears to be related with "Cannot insert a duplicate
key into unique index pg_attribute_relid_attnum_index" message. How can I
fix it?
Thanks a lot.
[postgres@dgtao postgres]$ /usr/bin/vacuumdb --analyze --verbose -d bxs >
/home/postgres/log4.txt 2>&1
[postgres@dgtao postgres]$ cat log4.txt
NOTICE: --Relation pg_type--
NOTICE: Pages 4: Changed 0, reaped 1, Empty 0, New 0; Tup 230: Vac 0,
Keep/VTL 0/0, Crash 0, UnUsed 51, MinLen 105, MaxLen 109; Re-using:
Free/Avail. Space 6124/0; EndEmpty/Avail. Pages 0/0. CPU 0.00s/0.02u sec.
NOTICE: Index pg_type_typname_index: Pages 7; Tuples 212: Deleted 0. CPU
0.00s/0.00u sec.
NOTICE: Index pg_type_typname_index: NUMBER OF INDEX' TUPLES (212) IS NOT
THE SAME AS HEAP' (230).
Recreate the index.
NOTICE: Index pg_type_oid_index: Pages 2; Tuples 234: Deleted 0. CPU
0.00s/0.00u sec.
NOTICE: Index pg_type_oid_index: NUMBER OF INDEX' TUPLES (234) IS NOT THE
SAME AS HEAP' (230).
Recreate the index.
NOTICE: --Relation pg_attribute--
NOTICE: Pages 57: Changed 1, reaped 39, Empty 3, New 0; Tup 1845: Vac 210,
Keep/VTL 0/0, Crash 29, UnUsed 1848, MinLen 98, MaxLen 100; Re
-using: Free/Avail. Space 251548/241720; EndEmpty/Avail. Pages 1/37. CPU
0.00s/0.14u sec.
NOTICE: Index pg_attribute_relid_attnum_index: Pages 24; Tuples 1506:
Deleted 0. CPU 0.00s/0.02u sec.
NOTICE: Index pg_attribute_relid_attnum_index: NUMBER OF INDEX' TUPLES
(1506) IS NOT THE SAME AS HEAP' (1845).
Recreate the index.
NOTICE: Index pg_attribute_relid_attnam_index: Pages 56; Tuples 1506:
Deleted 0. CPU 0.00s/0.03u sec.
NOTICE: Index pg_attribute_relid_attnam_index: NUMBER OF INDEX' TUPLES
(1506) IS NOT THE SAME AS HEAP' (1845).
Recreate the index.
ERROR: Cannot insert a duplicate key into unique index
pg_attribute_relid_attnum_index
vacuumdb: vacuum failed
[postgres@dgtao postgres]$
"Vilson farias" <vilson.farias@digitro.com.br> writes:
> The main problems appears to be related with "Cannot insert a duplicate
> key into unique index pg_attribute_relid_attnum_index" message. How can I
> fix it?
What platform are you running on, and how did you build or acquire the
executables? Have you ever run the regression tests?
This looks a lot like known portability problems on PPC, Alpha, etc.
There are workarounds but you need to know about them when building...
regards, tom lane
----- Original Message ----- From: Tom Lane <tgl@sss.pgh.pa.us> To: Vilson farias <vilson.farias@digitro.com.br> Cc: <pgsql-general@postgresql.org>; SIMONE Carla MOSENA <simone.mosena@digitro.com.br> Sent: Quinta-feira, 15 de Março de 2001 18:08 Subject: Re: [GENERAL] Why my vacuum fails? : "Vilson farias" <vilson.farias@digitro.com.br> writes: : > The main problems appears to be related with "Cannot insert a duplicate : > key into unique index pg_attribute_relid_attnum_index" message. How can I : > fix it? : : What platform are you running on, and how did you build or acquire the : executables? Have you ever run the regression tests? Linux RedHat 6.0 running on a K6-2. I installed using RPM packages and it's PostgreSQL 7.0.2. Nop, I never did a regression test. Is it necessary? Regards, José Vilson de Mello de Farias Dígitro Tecnologia Ltda. : : This looks a lot like known portability problems on PPC, Alpha, etc. : There are workarounds but you need to know about them when building... : : regards, tom lane : : ---------------------------(end of broadcast)--------------------------- : TIP 2: you can get off all lists at once with the unregister command : (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) :
Greetings again Tom and pgsql-general users,
I found another error. This time is when I execute vacuumdb. Why vacuum
stops at this point? Should it just create indexes and keep executing?
NOTICE: --Relation oper_juntor--
NOTICE: Pages 238: Changed 1, reaped 236, Empty 0, New 0; Tup 570: Vac
36739, Keep/VTL 0/0, Crash 0, UnUsed 45, MinLen 48, MaxLen 48; Re-u
sing: Free/Avail. Space 1770976/1768172; EndEmpty/Avail. Pages 0/235. CPU
0.05s/0.04u sec.
NOTICE: Index xpkoper_juntor: Pages 198; Tuples 582: Deleted 247. CPU
0.07s/0.01u sec.
NOTICE: Index xpkoper_juntor: NUMBER OF INDEX' TUPLES (582) IS NOT THE SAME
AS HEAP' (570).
Recreate the index.
<<vilson : execution stops here>>
Regards,
José Vilson de Mello de Farias
Dígitro Tecnologia Ltda - Brasil
----- Original Message -----
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Vilson farias <vilson.farias@digitro.com.br>
Cc: <pgsql-general@postgresql.org>; SIMONE Carla MOSENA
<simone.mosena@digitro.com.br>
Sent: Quinta-feira, 15 de Março de 2001 18:08
Subject: Re: [GENERAL] Why my vacuum fails?
: "Vilson farias" <vilson.farias@digitro.com.br> writes:
: > The main problems appears to be related with "Cannot insert a
duplicate
: > key into unique index pg_attribute_relid_attnum_index" message. How can
I
: > fix it?
:
: What platform are you running on, and how did you build or acquire the
: executables? Have you ever run the regression tests?
:
: This looks a lot like known portability problems on PPC, Alpha, etc.
: There are workarounds but you need to know about them when building...
:
: regards, tom lane
:
"Vilson farias" <vilson.farias@digitro.com.br> writes:
> : What platform are you running on, and how did you build or acquire the
> : executables? Have you ever run the regression tests?
> Linux RedHat 6.0 running on a K6-2.
> I installed using RPM packages and it's PostgreSQL 7.0.2.
Well, so much for my theory that it was an fmgr portability problem.
I don't know how your indexes got so messed up, but at this point I'd
recommend a dump/initdb/reload to get things straightened out. While
you are at it, it'd be a good idea to update to 7.0.3.
regards, tom lane
* Tom Lane <tgl@sss.pgh.pa.us> [010316 08:34] wrote: > "Vilson farias" <vilson.farias@digitro.com.br> writes: > > : What platform are you running on, and how did you build or acquire the > > : executables? Have you ever run the regression tests? > > > Linux RedHat 6.0 running on a K6-2. > > I installed using RPM packages and it's PostgreSQL 7.0.2. > > Well, so much for my theory that it was an fmgr portability problem. > > I don't know how your indexes got so messed up, but at this point I'd > recommend a dump/initdb/reload to get things straightened out. While > you are at it, it'd be a good idea to update to 7.0.3. 7.0.2 was really bad news for us. The absolute latest version of 7.0.3 has been working perfectly for months. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]