Re: Duplicate indexes found in the postgres Database

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: cjwhite(at)cisco(dot)com
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: Duplicate indexes found in the postgres Database
Date: 2003-02-06 15:05:59
Message-ID: 12347.1044543959@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

"Chris White" <cjwhite(at)cisco(dot)com> writes:
> User was able to recreate the problem, but this time only on table got
> duplicated 'gui_config'. So here is the info you wanted:

> select ctid,xmin,xmax,oid,* from pg_class where relname = 'gui_config';
> ctid | xmin | xmax | oid | relname | reltype | relowner | relam |
> relfilenode | relpages | reltuples | reltoastrelid | reltoastidxid |
> relhasindex | relisshared | relkind | relnatts | relchecks | reltriggers |
> relukeys | relfkeys | relrefs | relhasoids | relhaspkey | relhasrules |
> relhassubclass | relacl
> --------+------+------+-------+------------+---------+----------+-------+---
> ----------+----------+-----------+---------------+---------------+----------
> ---+-------------+---------+----------+-----------+-------------+----------+
> ----------+---------+------------+------------+-------------+---------------
> -+-----------------------
> (2,54) | 176 | 191 | 16560 | gui_config | 16561 | 101 | 0 |
> 16560 | 10 | 1000 | 0 | 0 | t |
> f | r | 2 | 0 | 0 | 0 |
> 0 | 0 | t | t | f | f |
> {=,aesop_gui=arwdRxt}
> (2,56) | 191 | 206 | 16560 | gui_config | 16561 | 101 | 0 |
> 16560 | 10 | 1000 | 0 | 0 | t |
> f | r | 2 | 0 | 0 | 0 |
> 0 | 0 | t | t | f | f |
> {=,aesop_gui=arwdRxt}
> (2 rows)

Hmm ... this looks much like the duplicate-tuple issues we were looking
at last month. Transaction 191 tried to update the row (though it's not
clear why, since none of the fields seem to have changed). But only one
of the two rows should be considered good --- either 191 committed or it
didn't. Something's gotten out of sync between the pg_class table file
and the pg_clog transaction commit status data. The only known ways for
that to happen involve system crashes just after a checkpoint, or pilot
error like trying to use a "tar" dump of an active database as a backup.

Is this a freshly-initdb'd database? Transaction number 191 seems very
small.

Do you have a procedure to reproduce the problem? Can you at least
describe what your user did?

regards, tom lane

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Geoffrey Wossum 2003-02-06 15:57:54 Re: Problems upgrading from 7.1.3
Previous Message Robert Treat 2003-02-06 14:58:41 Re: Update cascade on stmt, not on table definition