Re: pg_restore - table restoration - Mailing list pgsql-general

From Adrian Klaver
Subject Re: pg_restore - table restoration
Date
Msg-id 52D5D7E9.70609@gmail.com
Whole thread Raw
In response to Re: pg_restore - table restoration  ("Day, David" <dday@redcom.com>)
List pgsql-general
On 01/14/2014 02:29 PM, Day, David wrote:
> I note for the observed failure of pg_restore -c -a -t,
> I have worked around this by performing a
> Truncate operation on the tables prior to invoking
> pg_restore with a simpler -a -t option combination.
>
> If this matter needs to be reposted as bug or needs
> further action/information from me,  please advise.

Well the bug if there is one would to me be the dropping TABLE DATA below:

aklaver@panda:~> /usr/local/pgsql93/bin/pg_restore -c -v -a -t
student_sessions -t student_attendance -d hplc -U hplc_admin -p 5452
hplc.out
pg_restore: connecting to database for restore
pg_restore: dropping TABLE DATA student_sessions
pg_restore: dropping TABLE DATA student_attendance
pg_restore: processing data for table "student_attendance"
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 3145; 0 21204 TABLE
DATA student_attendance hplc_admin
pg_restore: [archiver (db)] COPY failed for table "student_attendance":
ERROR:  duplicate key value violates unique constraint
"student_attendance_pkey"
DETAIL:  Key (attendance_id)=(1) already exists.

Seems to me pg_restore either does what it reports, drop the data, or it
does not report dropping TABLE DATA because that is not actually happening.

At this point this has reached my limits of understanding. I would say
file a bug report, if for no other reason then to get a clarification on
what the behavior in this situation is meant to be.


>
> Thanks
>
> Dave
>



--
Adrian Klaver
adrian.klaver@gmail.com


pgsql-general by date:

Previous
From: "Day, David"
Date:
Subject: Re: pg_restore - table restoration
Next
From: Michael Paquier
Date:
Subject: Re: non-zero xmax yet visible