On 27 March 2012 15:12, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:
> On Tue, Mar 27, 2012 at 6:15 PM, Alban Hertroys <haramrae@gmail.com> wrote:
>>
>> On 27 March 2012 11:33, Akshay Joshi <akshay.joshi@enterprisedb.com>
>> wrote:
> pg_restore: restoring data for table "sample"
> pg_restore: [archiver (db)] Error while PROCESSING TOC:
> pg_restore: [archiver (db)] Error from TOC entry 1800; 0 54031 TABLE DATA
> sample postgres
> pg_restore: [archiver (db)] COPY failed for table "sample": ERROR: new
> row for relation "sample" violates check constraint
> "check_params_array_size"
> CONTEXT: COPY sample, line 1: "1 2 {}"
> pg_restore: restoring data for table "sample_one"
>
> As per the above log, it is clear that restoring of sample table start
> before sample_one and due to that my "check_params_array_size" constraint
> gets failed.
Aha, it's a check constraint! Those don't cover multiple tables, so
the order in which tables with check constraints get restored should
not matter.
In your case it apparently does matter, which seems to indicate that
you did something to circumvent that limitation and are now running
into problems because of that.
What's the definition of that constraint?
Perhaps a foreign key constraint would server you? Adding one should
at least make sure your database gets dumped in the correct order.
--
If you can't see the forest for the trees,
Cut the trees and you'll see there is no forest.