> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-trino-dialect.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# FAQ sur les migrations vers ClickHouse Managed Postgres
> Questions fréquemment posées sur la migration des données vers ClickHouse Managed Postgres.
export const PrivatePreviewBadge = () => {
return
{'Aperçu privé sur ClickHouse Cloud'}
;
};
De nombreuses questions sur le fonctionnement de la réplication de Postgres — notamment concernant les colonnes `TOAST`, les slots de réplication, les publications, les changements de schéma et les correspondances de types de données — sont abordées dans la [FAQ ClickPipes for Postgres](/fr/integrations/clickpipes/postgres/faq). Les informations qui y figurent s’appliquent également aux migrations vers ClickHouse Managed Postgres.
### Je rencontre une erreur "invalid input value for enum" pendant la réplication
Cette erreur se produit lorsque le Postgres source contient une valeur enum qui n'existe pas dans le ClickHouse Managed Postgres cible. La réplication logique ne propage pas automatiquement les commandes `ALTER TYPE ... ADD VALUE` ; par conséquent, les nouvelles valeurs enum ajoutées à la source après la configuration initiale du schéma entraîneront l'échec des insertions sur la cible.
Pour corriger ce problème, ajoutez la valeur manquante au type enum sur le Postgres cible :
```sql theme={null}
ALTER TYPE your_enum_type ADD VALUE 'new_value';
```
Remplacez `your_enum_type` par le nom de votre type enum et `'new_value'` par la valeur manquante indiquée dans le message d’erreur.
### Une erreur de violation de contrainte d’unicité ou de vérification survient pendant la réplication
Des violations de contraintes peuvent survenir lors de la réplication logique lorsque l’ordre de réplication entre en conflit avec une contrainte existante sur la cible.
* **Contraintes d’unicité** : Nous appliquons les modifications sous forme d’opérations `MERGE`/`UPSERT` par lots, qui écrivent la valeur la plus récente pour chaque clé primaire. L’ordre des opérations pour une clé donnée peut donc ne pas correspondre à celui attendu par l’index unique. Cela peut entraîner temporairement une violation d’une contrainte `UNIQUE` au sein de la transaction, même si la contrainte est respectée une fois le `MERGE` terminé. Postgres ne peut pas différer les vérifications d’index uniques comme il le fait pour les clés étrangères. Il n’est donc pas possible de reporter la vérification à la fin de la transaction. Cela n’affecte pas la cohérence des données : l’identité des lignes est définie par la clé primaire, et la logique du `MERGE` repose sur cette même clé primaire.
* **Contraintes de vérification** : Une contrainte de vérification sur la cible peut être plus stricte que sur la source, ou un état intermédiaire lors d’un `MERGE` par lots peut ne pas satisfaire la contrainte, même si l’état final la respecte. Comme pour les contraintes d’unicité, cela n’affecte pas la cohérence des données, car le `MERGE` repose sur la clé primaire qui définit l’identité des lignes.
Pour débloquer la réplication, supprimez la contrainte problématique du Postgres cible :
```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;
```
Vous pouvez obtenir les détails de la contrainte à l’aide du nom indiqué dans le message d’erreur :
```sql theme={null}
SELECT conname, conrelid::regclass, contype
FROM pg_constraint
WHERE conname = 'your_constraint_name';
```
Réappliquez les contraintes lors du basculement, une fois la réplication terminée et la source n’est plus 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);
```