Subject: How does cbcopy handle a duplicate value conflict when the DISTRIBUTED BY column is also the PRIMARY KEY? Context: I'm migrating a production database from Greenplum 7 to Apache Cloudberry 2.0.1 using cbcopy. One of the tables (~880 million rows) has its DISTRIBUTED BY column also defined as the PRIMARY KEY. Question: If the source table contains duplicate values in this column — for example due to a constraint that was disabled or marked NOT VALID at some point on the source side — what is cbcopy's actual behavior when loading into a target table where the PRIMARY KEY constraint is active? Specifically: 1. Does cbcopy do any pre-check on this column before starting the load, or does it just attempt the insert and let the target's constraint layer catch it? 2. When a duplicate key violation happens mid-load, does the entire table/partition load abort and roll back, or does it skip the conflicting row(s) and continue with the rest? 3. Is there any flag or option to control this behavior — for example, skipping and logging conflicting rows versus a hard failure? I'd like a definitive answer before running this on a table this large in production, rather than relying on trial-and-error. Any insight from someone who has hit this scenario during a large-scale migration would help a lot. Environment: • Source: Greenplum 7.x • Target: Apache Cloudberry 2.0.1 • Table size: ~880 million rows • Column: DISTRIBUTED BY + PRIMARY KEY (same column)