Обсуждение: Re: [HACKERS] Number of tuples (20300) not the same as heap (20301)

I see this problem all the time too. There are some scary bugs in the bowels
of the code that controls indexes and primary keys.

At this point, I have like 4000 duplicated primary keys, and I cannot update
sections of the table due to key violations.

Tim Perdue
PHPBuilder.com / GotoCity.com / Geocrawler.com


-----Original Message-----
From: G. Anthony Reina <reina@nsi.edu>
To: pgsql-hackers@postgreSQL.org <pgsql-hackers@postgreSQL.org>
Date: Monday, April 26, 1999 8:14 PM
Subject: [HACKERS] Number of tuples (20300) not the same as heap (20301)


>I have a table in which the first four variables are the unique primary
>key. Recently, I ran a vacuum and was told that the number of tuples did
>not equal the number in the heap for the primary key index to this
>table. I'm not exactly sure whatn this means. It sounds like one or more
>of the "unique" keys may have more than one set of data.
>
>I often update the table using a text file containing the "UPDATE
>table_name SET ..." and running the \i command in psql to execute the
>commands from the text file.  For some of these updates, I update an
>variable length array that sometimes is longer than 8K. So what I do is
>just update the first 100 or so positions in that array and get the
>remaining positions with another update. I'm wondering if somehow there
>is a bug that doesn't like this a ocassionally screws up the indexing.
>
>Anyone know what this error means? I've tried dropping the index and
>re-creating it but still get the same error on a vacuum.
>
>
>Thanks.
>-Tony
>
>

Tim Perdue wrote:

> I see this problem all the time too. There are some scary bugs in the bowels
> of the code that controls indexes and primary keys.
>
> At this point, I have like 4000 duplicated primary keys, and I cannot update
> sections of the table due to key violations.
>
> Tim Perdue
> PHPBuilder.com / GotoCity.com / Geocrawler.com
>

My co-worker fixed the table in question but the fix was kind of kludgy. He
performed a select on the table and outputted it to a text file. Then he wrote
a C program to search the text file for cases of two or more datasets in any
primary key. He then deleted the extra datasets with this search list. Lastly,
he vacuumed the corrected table. (Apparently, our searching on this table was
extremely slow because the vacuum doesn't work if you get this type of error).

Maybe you could find a similar fix for your table.

Hopefully, some of the hackers will be able to find the problem in the code.
Otherwise, the db works very well.
-Tony