BUG #2455: psql failing to restore a table because of a constaint violation.

From: "Jeff Ross" <jross(at)wykids(dot)org>
To: pgsql-bugs(at)postgresql(dot)org
Subject: BUG #2455: psql failing to restore a table because of a constaint violation.
Date: 2006-05-25 21:09:45
Message-ID: 200605252109.k4PL9jho085545@wwwmaster.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs


The following bug has been logged online:

Bug reference: 2455
Logged by: Jeff Ross
Email address: jross(at)wykids(dot)org
PostgreSQL version: 8.1.4
Operating system: OpenBSD 3.9 -current
Description: psql failing to restore a table because of a constaint
violation.
Details:

After the upgrade to 8.1.4, this script I use to sync a development database
with our live database began failing.

Here's the script:

#!/bin/sh
#backup script for postgresql databases
#
DATE=`date +%Y%m%d`
#dump the live wykids database
/usr/local/bin/pg_dumpall -p 5432 -c > \
/home/_postgresql/wykids$DATE.sql
#drop the development wykids database
/usr/local/bin/dropdb -p 5435 wykids
#recreate the development wykids database from the dump file we just made
/usr/local/bin/psql -p 5435 template1 -f \
/home/_postgresql/wykids$DATE.sql

Here's the failure:

psql:/home/_postgresql/wykids20060524.sql:84507: ERROR: new row for
relation "Clearinghouse" violates check
constraint "refnumber_ck"

CONTEXT: COPY Clearinghouse, line 1: "Video Three R's for Special Education
School Age Uniqueness and
Cultural Awareness 0.5 total 49.9500..."

Here's the record it barfs on:

wykids=# select * from "Clearinghouse" where "Training Material"
ilike('%three r%');
-[ RECORD 1 ]-----+----------------------------------
Type | Video
Training Material | Three R's for Special Education
Category | School Age
Section Found In | Uniqueness and Cultural Awareness
Clock Hours | 0.5
Notes | total
Price | 49.95
# books | 1
RefNumber | V207.030

Here's the table structure:

wykids=# \d "Clearinghouse"
Table "public.Clearinghouse"
Column | Type | Modifiers
-------------------+-----------------------+-----------
Type | character varying(50) |
Training Material | character varying(75) |
Category | character varying(50) |
Section Found In | character varying(50) |
Clock Hours | real |
Notes | character varying(50) |
Price | double precision |
# books | character varying(10) |
RefNumber | character varying(30) | not null
Indexes:
"clearinghouse_old_pk" PRIMARY KEY, btree ("RefNumber")
Check constraints:
"refnumber_ck" CHECK ("RefNumber"::text ~
similar_escape('[A-Z]|[0-9]|.'::text, NULL::text))
Rules:
refnumber_uppercase_ins AS
ON INSERT TO "Clearinghouse" DO UPDATE "Clearinghouse" SET
"RefNumber" = upper(new."RefNumber"::text)
WHERE "Clearinghouse"."RefNumber"::text = new."RefNumber"::text

The value in the record cited doesn't violate the constraint, and removing
that record from the .sql file
caused the same failure on the very next record.

Using pg_dump -Fc instead also failed.

As a workaround, we dropped the constraint (not critical) to make sure we
still had backup capability.

Jeff Ross

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Vivekananda 2006-05-26 12:42:33 BUG #2456: How to write user defined functions in Postgress sql
Previous Message Tom Lane 2006-05-24 21:29:34 Re: "blah" is not a domain error