GitHub user asheraz048i2c created a discussion: 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: 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? 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? 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) GitHub link: https://github.com/apache/cloudberry/discussions/2050 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
