Re: [SQL] Duplicate tuples with unique index - Mailing list pgsql-sql

From Palle Girgensohn
Subject Re: [SQL] Duplicate tuples with unique index
Date
Msg-id 388E406E.D591309E@partitur.se
Whole thread Raw
In response to Re: [SQL] Duplicate tuples with unique index  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: [SQL] Duplicate tuples with unique index  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-sql
Bruce Momjian wrote:
> 
> > Palle Girgensohn <girgen@partitur.se> writes:
> > > Unfotunately, it doesn't quite work:
> >
> > > pp=> vacuum analyze;
> > > NOTICE:  Rel pg_statistic: TID 1/93: OID IS INVALID. TUPGONE 0.
> > > VACUUM
> > > pp=> delete from pg_statistic;
> > > ERROR:  heap_delete: (am)invalid tid
> >
> > Ugh.  Yup, your pg_statistic table is corrupted all right.
> >
> > What you may have to do is pg_dump that database, destroydb/createdb,
> > and reload.
> >
> > I have a possible shortcut for you, but I *strongly* suggest that you
> > pg_dump first in case it doesn't work!  After making your backup dump,
> > stop the postmaster and truncate the broken database's pg_statistic
> > file to zero length:
> >       cp /dev/null .../data/base/yourdb/pg_statistic
> > Then restart the postmaster and see if you can vacuum analyze the
> > broken database.  If so, you are good to go; if not, it's time to
> > reload that database.
> >
> 
> Running pg_upgrade is another option.

Nope. pg_upgrade was "disabled in this release because the internal blahblahblah disk layout changed from previous
versions".cat /dev/null > pg_statistic didn't help, and the file was already zero
 
bytes long.

Applied the patches to vacuum.c and hio.c, and pg_dumpall && initdb && psql < dump.sql fixed it.

Thanks for your support! 

/Palle


pgsql-sql by date:

Previous
From: Palle Girgensohn
Date:
Subject: Re: [SQL] Problem with large tuples.
Next
From: Palle Girgensohn
Date:
Subject: Re: [SQL] Duplicate tuples with unique index