Re: ERROR: cannot insert duplicate... on VACUUM ANALYZE

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: lapham(at)extracta(dot)com(dot)br
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: ERROR: cannot insert duplicate... on VACUUM ANALYZE
Date: 2001-10-09 16:07:47
Message-ID: 3245.1002643667@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Jon Lapham <lapham(at)extracta(dot)com(dot)br> writes:
> Tom, before answering your questions, I should also say that the *first*
> time I ran VACUUM ANALYZE I actually received 2 messages, the one I've
> already reported and also "NOTICE: Rel pg_type: TID 3/3: OID IS INVALID.
> TUPGONE 1.". The second and subsequent runs of VACUUM ANALYZE did not
> include this second message.

Hmm, this is disturbing; it suggests data's been clobbered on disk
somehow.

> The platform is linux, RH7.1 with all errata patches applied, running on
> an AMD 1300. Postgresql v7.1.2, compiled thusly: " --with-tcl
> --with-perl --with-odbc --enable-hba --enable-locale" (so I am using
> locale, if that matters). I am running the postmaster with "-B 1000".

An update to 7.1.3 might be well-advised, but I am not sure that I can
connect this problem to any of the bugs fixed in 7.1.3. On the locale
front, I sure hope you have glibc 2.2.3 or later installed, else you
are subject to the known problems with 2.2.2's strcoll().

However, since the index in question is on an int2 column, it wouldn't
be affected by strcoll(). So that still leaves us with no good theory
about what happened.

You can probably recover from the immediate problem by rebuilding the
damaged index (use REINDEX, or just drop and recreate the index).
However, that won't do anything to prevent it from happening again...

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Janning Vygen 2001-10-09 16:22:10 Creating html form definitions for a frontend inside postgresql??
Previous Message Dave Cramer 2001-10-09 15:12:42 Re: Sqlstatement with !=-1 fails