Hi,
This is sort of a continuation of = problems I was working on last week
with selective restorations of an archive file at the schema or table level. ( V9.3)
Given that I dumped the entire database ( pg_dump –Fc my_db –f archive_file )
When I pg_restore an entire schema ( -n ) everything is wonderful.
If I try to attempt two tables in one of the schemas I encounter problems.
I get a success of sort with these option variations:
pg_restore -c -t tbl1 –t tbl2 –U <username> -d my_db archive_file
In this case the tables are recreated with data but all the original constraints for these tables are missing
As are triggers that are associated with the tables. I guess I can understand this.
This variation seems encouranging but ultimately fails:
pg_restore –a –v -c -t translator_sys –t translator_sys_mbr –U <username> -d my_db archive_file
pg_restore: connecting to database for restore
pg_restore: dropping TABLE DATA translator_sys
pg_restore: dropping TABLE DATA translator_sys_mbr
pg_restore: dropping TABLE DATA translator_sys
pg_restore: processing data for table "translator_sys"
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 4247; 0 332255 TABLE DATA translator_sys redcom
pg_restore: [archiver (db)] COPY failed for table "translator_sys": ERROR: duplicate key value violates unique constraint "translator_sys_pkey"
DETAIL: Key (translator_id)=(1) already exists.
CONTEXT: COPY translator_sys, line 1
pg_restore: processing data for table "translator_sys_mbr"
pg_restore: [archiver (db)] Error from TOC entry 4248; 0 332262 TABLE DATA translator_sys_mbr redcom
pg_restore: [archiver (db)] COPY failed for table "translator_sys_mbr": ERROR: duplicate key value violates unique constraint "translator_sys_mbr_pkey"
DETAIL: Key (translator_id, tid_seq)=(1, 1) already exists.
CONTEXT: COPY translator_sys_mbr, line 1
pg_restore: processing data for table "translator_sys"
It seems like it is geared to TRUNCATE or DELETE the specified table data in this case based on the verbose output.
However I see no SQL commands in the std_out to support this verbose message so it ultimately fails because of the
Duplication of PK associated with the table..
Is this a bug or a mis-understanding on my part?
Regards
Dave Day
