[SCRIPT] pguniqchk -- checks uniqueness of unique constraints on tables

From: "David D(dot) Kilzer" <ddkilzer(at)lubricants-oil(dot)com>
To: pgsql-hackers(at)postgresql(dot)org, pgsql-general(at)postgresql(dot)org
Cc: Debian PostgreSQL Maintainer <Oliver(dot)Elphick(at)lfix(dot)co(dot)uk>
Subject: [SCRIPT] pguniqchk -- checks uniqueness of unique constraints on tables
Date: 2002-09-06 21:06:24
Message-ID: 20020906160624.A20549@elbonia.lubricants-oil.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

From the Department of Redundancy Department:

Attached is a perl script called 'pguniqchk'. It checks the uniqueness
of unique constraints on tables in a PostgreSQL database using the
PG_TABLES and PG_INDEXES system "tables".

Why would this be useful?

If you're planning to dump and restore the database, this might be a
good sanity check to run before doing it.

Apparently, when such an impossible event occurs, the unique index on
the table only "sees" one of the duplicate rows. In order to even query
both rows, one must run this SQL command (via psql) to turn off index
scans:

=> set enable_indexscan = off;

The attached script does this, then verifies the uniqueness of the
unique index by scanning the entire table.

It is probably useless for 99.999% of PostgreSQL users, but I thought
I'd share it just in case someone finds it useful, even if only
as a simple example of querying system tables.

How I found the problem:

I had a need to alter the data types of a column on two different tables
(VARCHAR(32) -> VARCHAR(128) and VARCHAR(128) -> TEXT) and drop a column
from another table. The only way to do this in v7.1.x is to perform a
full dump and then restore. When I tried to reload the data, I got
unique key violation errors, and data for two other tables did not load.

As it turns out, one table had a single pair of duplicate keys while the
other table had five pair of duplicates and one set of triplicates.

The incident happened around April 05, 2002 (from what I can tell of
the duplicated data), but hasn't happened since. I was having SCSI
disk errors around that time on my production server, which is the prime
suspect.

NOTES:

- Only tested on PostgreSQL 7.1.3.

- When a UNIQUE INDEX is put on a NULLABLE column, duplicates with NULL
values are possible. This is a feature, though the script does not
check for this case (so don't be alarmed if it finds something).

7.4. Unique Indexes
http://www.postgresql.org/idocs/index.php?indexes-unique.html

Dave

Attachment Content-Type Size
pguniqchk text/plain 6.1 KB

Browse pgsql-general by date

  From Date Subject
Next Message Darren Ferguson 2002-09-06 22:04:31 Re: Screwy Statistics...
Previous Message Mihai Gheorghiu 2002-09-06 20:09:53 Re: Surprise :-(

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2002-09-06 22:01:10 Re: beta1 packaged
Previous Message Greg Copeland 2002-09-06 20:23:40 Re: Inheritance