> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-framing-web-ui.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# ClickHouse Managed Postgres migrations FAQ
> Frequently asked questions about migrating data to ClickHouse Managed Postgres.
export const PrivatePreviewBadge = () => {
return
{'Private preview in ClickHouse Cloud'}
;
};
Many questions about how Postgres replication works — including `TOAST` columns, replication slots, publications, schema changes, and data type mappings — are covered in the [ClickPipes for Postgres FAQ](/integrations/clickpipes/postgres/faq). The information there applies to ClickHouse Managed Postgres migrations as well.
I'm seeing an "invalid input value for enum" error during replication
This error occurs when the source Postgres has an enum value that doesn't exist on the target ClickHouse Managed Postgres. Logical replication doesn't automatically propagate `ALTER TYPE ... ADD VALUE` commands, so new enum values added on the source after the initial schema setup will cause inserts to fail on the target.
To fix this, add the missing value to the enum type on the target Postgres:
```sql theme={null}
ALTER TYPE your_enum_type ADD VALUE 'new_value';
```
Replace `your_enum_type` with the name of your enum type and `'new_value'` with the missing value from the error message.
I'm seeing a unique constraint or check constraint violation error during replication
Constraint violations can occur during logical replication when the replication order causes a conflict with an existing constraint on the target.
* **Unique constraints**: We apply changes as batched `MERGE`/`UPSERT` operations that write the latest value per primary key, so the order of operations for a given key may not match the ordering the unique index expects. This can temporarily violate a `UNIQUE` constraint within the transaction, even though the constraint holds once the `MERGE` completes. Postgres cannot defer unique index checks the way it defers foreign keys, so there is no way to postpone the check to the end of the transaction. This does not affect data consistency: row identity is defined by the primary key, and the `MERGE` logic is keyed on that same primary key.
* **Check constraints**: A check constraint on the target may be stricter than the source, or an intermediate state during a batched `MERGE` may not satisfy the constraint even though the final state does. As with unique constraints, this does not affect data consistency, since the `MERGE` is keyed on the primary key that defines row identity.
To unblock replication, drop the offending constraint on the target Postgres:
```sql theme={null}
-- Drop a unique constraint
ALTER TABLE your_table DROP CONSTRAINT your_constraint_name;
-- Drop a check constraint
ALTER TABLE your_table DROP CONSTRAINT your_check_constraint_name;
```
You can find the constraint details using the name from the error message:
```sql theme={null}
SELECT conname, conrelid::regclass, contype
FROM pg_constraint
WHERE conname = 'your_constraint_name';
```
Re-add the constraints during cutover, once replication is complete and the source is no longer active:
```sql theme={null}
ALTER TABLE your_table ADD CONSTRAINT your_constraint_name UNIQUE (column1, column2);
ALTER TABLE your_table ADD CONSTRAINT your_check_constraint_name CHECK (column1 > 0);
```