FAQ sur ClickHouse Managed Postgres

Monitoring et métriques

Comment puis-je accéder aux métriques de mon instance ClickHouse Managed Postgres ?

Vous pouvez surveiller l’utilisation du CPU, de la mémoire, des IOPS et du stockage directement dans la console ClickHouse Cloud, dans l’onglet Monitoring de votre instance ClickHouse Managed Postgres. De plus, vous pouvez consulter Query Performance Insights pour obtenir une analyse détaillée de vos requêtes dans l’onglet Query Insights.

Sauvegarde et restauration

Quelles options de sauvegarde sont disponibles ?

ClickHouse Managed Postgres inclut des sauvegardes automatiques quotidiennes avec archivage continu du WAL, permettant une restauration à un instant donné à tout moment dans une période de rétention de 7 jours. Les sauvegardes sont stockées dans le stockage objet. Pour plus de détails sur la fréquence des sauvegardes, la rétention et la procédure de restauration à un instant donné, consultez la documentation Sauvegarde et restauration.

Infrastructure et automatisation

Quels fournisseurs cloud sont pris en charge ?

ClickHouse Managed Postgres est disponible sur AWS en public beta. GCP est en private preview. Vous pouvez vous inscrire sur la liste d’attente de la private preview GCP ici et consulter l’annonce pour en savoir plus. Consultez Fournisseurs cloud pris en charge pour plus de détails.

Terraform est-il pris en charge pour ClickHouse Managed Postgres ?

Oui. Vous pouvez créer et gérer des services ClickHouse Managed Postgres avec le Terraform provider ClickHouse en utilisant la resource clickhouse_postgres_service. Consultez la référence Terraform pour plus de détails. Vous pouvez également utiliser la console ClickHouse Cloud ou OpenAPI pour créer et gérer vos instances.

Extensions et configuration

Quelles extensions sont prises en charge ?

ClickHouse Managed Postgres inclut plus de 90 extensions PostgreSQL, dont des extensions populaires comme PostGIS, pg_cron, pgvector et bien d’autres. Pour consulter la liste complète des extensions disponibles ainsi que les instructions d’installation, reportez-vous à la documentation Extensions.

Puis-je personnaliser les paramètres de configuration de PostgreSQL ?

Oui, vous pouvez modifier les paramètres de configuration de PostgreSQL et de PgBouncer via l’onglet Settings de la console. Pour en savoir plus sur les paramètres disponibles et sur la manière de les modifier, consultez la documentation Settings.

Si vous avez besoin d’un paramètre qui n’est pas disponible pour le moment, contactez le support pour en faire la demande.

Pool de connexions

Pourquoi des erreurs `prepared statement does not exist` apparaissent-elles via PgBouncer ?

ClickHouse Managed Postgres exécute PgBouncer en mode pool de connexions par transaction. Dans ce mode, une connexion Postgres backend n’est assignée à votre client que le temps d’une seule transaction, puis elle est restituée au pool — la transaction suivante du même client peut donc être routée vers un autre backend. PgBouncer suit les requêtes préparées au niveau du protocole, que la plupart des drivers envoient via le protocole de requête étendu (messages Parse, Bind et Execute). Lorsqu’un statement s’exécute sur un backend qui ne le connaît pas encore, PgBouncer l’y prépare au préalable. Chaque connexion backend en conserve jusqu’à max_prepared_statements, soit 200 par défaut. La plupart des drivers fonctionnent donc via PgBouncer avec leurs paramètres par défaut. Ce qui ne fonctionne pas via PgBouncer :

Les requêtes préparées au niveau SQL. PgBouncer ne suit pas les commandes PREPARE et EXECUTE envoyées en SQL ; un EXECUTE peut donc être routé vers un backend qui n’a jamais exécuté le PREPARE.
La libération des statements avec la commande SQL DEALLOCATE. PgBouncer renomme les statements sur le backend, si bien qu’un DEALLOCATE portant sur le nom de statement utilisé par le client échoue. Au sein d’une transaction, cet échec interrompt la transaction, et les statements suivants échouent avec current transaction is aborted. Les drivers reposant sur libpq 17 ou version ultérieure libèrent quant à eux les statements à l’aide d’un message Close au niveau du protocole, que PgBouncer prend en charge.
Les statements non nommés répartis sur plusieurs allers-retours. Certains modes de driver envoient le Parse d’un statement non nommé lors d’un aller-retour, puis son Bind lors du suivant. PgBouncer peut alors exécuter le second aller-retour sur un autre backend : l’opération échoue avec unnamed prepared statement does not exist, ou bien le statement d’un autre client est exécuté silencieusement et ses résultats sont renvoyés.

Dans ces cas, on obtient des erreurs telles que :

ERROR:  prepared statement "..." does not exist
ERROR:  unnamed prepared statement does not exist
ERROR:  prepared statement did not exist

Voici quelques symptômes qui découlent souvent de la même cause profonde :

Des pics d’erreurs prepared statement does not exist, en particulier lors de backfills ou d’écritures à forte concurrence
Des insertions qui semblent « échouer silencieusement » : le statement renvoie une erreur, le driver effectue de nouvelles tentatives, et un batch peut finir par être partiellement appliqué ou perdu
Des transactions qui échouent avec current transaction is aborted après la libération d’un statement
Des lignes qui appartiennent à une autre requête

Solution : utilisez le paramètre correspondant à votre driver ci-dessous. Si votre driver ne figure pas dans la liste, mettez-le à niveau vers une version qui utilise libpq 17 ou version ultérieure, ou désactivez-y les requêtes préparées côté serveur.

Driver	Via PgBouncer
node-postgres / pg (Node.js)	Aucune modification nécessaire.
Bun.sql (Bun)	Aucune modification nécessaire. Si l’erreur `prepared statement does not exist` apparaît, définissez `prepare: false`.
Prisma avec `@prisma/adapter-pg`	Aucune modification nécessaire. Le paramètre d’URL `pgbouncer=true` n’a aucun effet dans Prisma 7.
psycopg 3 (Python, Django)	Aucune modification nécessaire avec `psycopg[binary]` ou avec libpq 17 ou version ultérieure. Avec une version plus ancienne de libpq, définissez `prepare_threshold=None`. Django utilise par défaut la liaison côté client ; aucune modification n’est donc nécessaire.
asyncpg (Python, SQLAlchemy)	Aucune modification nécessaire. Si vous désactivez le cache de statements avec `statement_cache_size=0` sous SQLAlchemy, définissez également `prepared_statement_cache_size=0` dans l’URL.
pgjdbc (Java)	Aucune modification nécessaire. Utilisez pgjdbc 42.7.5 ou version ultérieure ; les versions antérieures ne peuvent pas se connecter via PgBouncer. Voir `unsupported startup parameter`.
Npgsql (.NET)	Aucune modification nécessaire : la préparation automatique est désactivée par défaut. N’activez pas `Max Auto Prepare` et n’appelez pas `Prepare` via PgBouncer ; si vous y êtes contraint, définissez également `No Reset On Close=true`.
pgx (Go)	Définissez `default_query_exec_mode=cache_describe` (ou `exec`). N’utilisez jamais `describe_exec`, qui répartit les statements non nommés sur plusieurs allers-retours.
Postgrex / Ecto (Elixir)	Définissez `prepare: :unnamed` dans la configuration de votre repo. Avec des statements nommés, une requête d’environ 4 Ko peut rester bloquée via PgBouncer.
sqlx (Rust)	Aucun paramètre lié aux requêtes préparées n’est nécessaire. N’utilisez ni `.persistent(false)` ni `statement_cache_capacity(0)`. Pour que la connexion puisse s’établir, définissez `extra_float_digits(None)` ; voir `unsupported startup parameter`.
Active Record (Ruby on Rails)	Aucune modification nécessaire avec la gem `pg` 1.6 ou version ultérieure et libpq 17 ou version ultérieure. Sinon, définissez `prepared_statements: false` dans `config/database.yml`.
PDO (PHP, Laravel)	Aucune modification nécessaire lorsque `pdo_pgsql` est compilé avec libpq 17 ou version ultérieure. Sinon, définissez `PDO::ATTR_EMULATE_PREPARES => true`.

Si votre charge de travail repose sur PREPARE au niveau SQL, connectez-vous directement à PostgreSQL (port 5432) plutôt qu’au pooler PgBouncer. Consultez Connexion pour savoir comment choisir entre l’endpoint avec pooling et l’endpoint direct.

Pourquoi les requêtes échouent-elles avec `cached plan must not change result type` après une migration ?

PgBouncer conserve les requêtes préparées sur ses connexions Postgres et les réutilise pour un même texte SQL. Après une modification de schéma qui change le type d’une colonne renvoyée par une requête (par exemple de integer à bigint), cette requête continue d’échouer via PgBouncer avec l’erreur cached plan must not change result type. L’échec persiste même depuis de nouvelles connexions client, tant que PgBouncer n’a pas remplacé ses connexions Postgres. Certains drivers, eux, décodent les types de résultat obsolètes et renvoient des valeurs erronées sans signaler d’erreur. Via la connexion directe, chaque connexion échoue au plus une fois, puis se rétablit. Pour résoudre le problème, fermez les connexions Postgres de PgBouncer pour cette base de données : PgBouncer en ouvrira de nouvelles. Comme PgBouncer se connecte à Postgres en local, ses connexions n’ont pas de client_addr. Exécutez la commande suivante via la connexion directe (port 5432), avec le même utilisateur que votre application. Elle ne met fin qu’aux connexions de PgBouncer associées à l’utilisateur de votre application : les transactions en cours via PgBouncer à ce moment-là échoueront, mais les connexions directes ne seront pas affectées :

SELECT pg_terminate_backend(pid) FROM pg_stat_activity
WHERE datname = '<your_database>' AND usename = current_user
  AND client_addr IS NULL AND backend_type = 'client backend'
  AND pid <> pg_backend_pid();

Les drivers qui utilisent des statements non nommés, comme Npgsql avec sa configuration par défaut, Postgrex avec prepare: :unnamed ou pgx avec cache_describe, ne sont pas concernés.

Pourquoi l’erreur `unsupported startup parameter` apparaît-elle avec PgBouncer ?

PgBouncer rejette les paramètres définis à l’ouverture de la connexion qu’il ne peut pas appliquer de manière cohérente à l’ensemble de ses connexions Postgres mutualisées, et renvoie alors l’erreur FATAL: unsupported startup parameter: ... ou unsupported startup parameter in options: .... Les cas les plus courants sont les suivants :

extra_float_digits, que pgjdbc 42.7.4 et versions antérieures (par exemple avec Spring Boot 3) ainsi que sqlx envoient à chaque connexion. Mettez à niveau pgjdbc vers la version 42.7.5 ou ultérieure. Dans sqlx, définissez extra_float_digits(None) sur PgConnectOptions.
search_path et les autres paramètres passés dans la chaîne de connexion, comme currentSchema dans une URL JDBC, Search Path dans une chaîne de connexion Npgsql, options=-c ... ou OPTIONS["options"] dans Django. Définissez plutôt la valeur par défaut avec ALTER ROLE ... SET ou ALTER DATABASE ... SET, utilisez SET LOCAL au sein d’une transaction, ou connectez-vous directement.

application_name et TimeZone sont pris en charge.

Pourquoi les commandes `SET` ne sont-elles pas conservées avec PgBouncer ?

En mode pool de connexions par transaction, un SET au niveau de la session s’applique à la connexion Postgres qui l’a exécuté, et non à votre client. Les transactions suivantes de votre client peuvent s’exécuter sur d’autres connexions où ce paramètre n’est pas défini, tandis que d’autres clients peuvent s’exécuter sur la connexion où il l’est. Cela vaut aussi pour SET ROLE : un rôle que vous assumez peut donc s’appliquer aux requêtes d’un autre client. Utilisez SET LOCAL à l’intérieur d’une transaction, définissez des valeurs par défaut avec ALTER ROLE ... SET ou ALTER DATABASE ... SET, ou connectez-vous directement pour les charges de travail qui reposent sur l’état de session.

Pourquoi les migrations se bloquent-elles ou n’arrivent-elles pas à libérer un verrou consultatif via PgBouncer ?

De nombreux outils de migration acquièrent un verrou consultatif au niveau de la session afin qu’une seule migration s’exécute à la fois, puis le libèrent au moyen d’un statement distinct. Avec PgBouncer, cette libération peut s’exécuter sur une autre connexion Postgres, et le verrou reste alors détenu par une connexion du pool. Les migrations suivantes restent dès lors en attente ou échouent avec des erreurs telles que failed to release advisory lock, même via la connexion directe. Parmi les outils qui utilisent des verrous consultatifs de session figurent golang-migrate, sqlx, le Migrator de Kysely, Rails, Flyway avec transactional-lock=false et Ecto avec migration_lock: :pg_advisory_lock. Exécutez les migrations via la connexion directe (port 5432). Un verrou orphelin est détenu par une session inactive, alors qu’une migration encore en cours détient son verrou depuis une session active. Pour supprimer les verrous orphelins, mettez fin uniquement aux sessions inactives qui détiennent des verrous consultatifs dans votre base de données, là encore via la connexion directe :

SELECT pg_terminate_backend(l.pid) FROM pg_locks l
JOIN pg_stat_activity a ON a.pid = l.pid
WHERE l.locktype = 'advisory' AND a.state = 'idle'
  AND l.database = (SELECT oid FROM pg_database WHERE datname = current_database());

Que signifie le paramètre `max_client_conn` dans PgBouncer, et comment se compare-t-il à `max_connections` dans Postgres ?

Ils ne contrôlent pas la même chose :

Postgres max_connections fixe le nombre maximal de connexions backend à PostgreSQL lui-même. C’est la limite la plus coûteuse : chaque backend consomme de la mémoire et un slot de processus.
PgBouncer max_client_conn fixe le nombre maximal de connexions client pouvant être ouvertes simultanément dans le pooler. PgBouncer multiplexe ce grand nombre de connexions client sur un ensemble bien plus réduit de connexions backend.

PgBouncer accepte plusieurs fois plus de connexions client que de backends Postgres. Par exemple, une instance dont max_connections est défini sur 500 accepte 2500 connexions client au niveau du pooler. Si vous voyez des erreurs de connexion au niveau du pooler, il est bien plus probable que vous atteigniez une limite backend par pool (default_pool_size, ou max_db_connections par base de données) plutôt que la limite client globale. Pour consulter les valeurs de votre instance, connectez-vous à la base de données spéciale pgbouncer via PgBouncer (port 6432) et exécutez SHOW CONFIG :

psql "postgresql://postgres:<PASSWORD>@your-instance.pg.clickhouse.cloud:6432/pgbouncer?sslmode=verify-full&sslrootcert=ca-certificate.pem" -c "SHOW CONFIG;"

Fonctionnalités de la base de données

Puis-je créer plusieurs bases de données et schémas ?

Oui. ClickHouse Managed Postgres offre toutes les fonctionnalités natives de PostgreSQL, notamment la prise en charge de plusieurs bases de données et schémas au sein d’une même instance. Vous pouvez créer et gérer des bases de données et des schémas à l’aide des commandes PostgreSQL standard.

Le contrôle d’accès basé sur les rôles (RBAC) est-il pris en charge ?

Vous bénéficiez d’un accès superutilisateur complet à votre instance ClickHouse Managed Postgres, ce qui vous permet de créer des rôles et de gérer les autorisations à l’aide des commandes PostgreSQL standard.

Des fonctionnalités RBAC avancées avec intégration à la Console sont prévues cette année.

Mises à niveau

Comment les mises à niveau de version de PostgreSQL sont-elles gérées ?

Les mises à niveau, mineures comme majeures, sont effectuées par basculement et n’entraînent généralement que quelques secondes d’indisponibilité. Vous pouvez configurer des mises à niveau planifiées pour contrôler les jours et la fenêtre UTC de deux heures durant laquelle les mises à niveau sont appliquées. Pour plus de détails, consultez la documentation Mises à niveau.

Migration

Quels outils sont disponibles pour migrer vers ClickHouse Managed Postgres ?

ClickHouse Managed Postgres prend en charge plusieurs méthodes de migration :

pg_dump and pg_restore : pour les bases de données de petite taille ou les migrations ponctuelles. Consultez le guide pg_dump and pg_restore.
réplication logique : pour les bases de données plus volumineuses nécessitant un minimum d’indisponibilité. Consultez le guide réplication logique.
PeerDB : pour la réplication basée sur le CDC à partir d’autres sources Postgres. Consultez le guide migration avec PeerDB.

Une expérience de migration entièrement gérée sera bientôt disponible.

Premiers pas

Fonctionnalités

Guides

Tarification

Intégration ClickHouse

Migrations

Supervision

FAQ

Monitoring et métriques

Comment puis-je accéder aux métriques de mon instance ClickHouse Managed Postgres ?

Sauvegarde et restauration

Quelles options de sauvegarde sont disponibles ?

Infrastructure et automatisation

Quels fournisseurs cloud sont pris en charge ?

Terraform est-il pris en charge pour ClickHouse Managed Postgres ?

Extensions et configuration

Quelles extensions sont prises en charge ?

Puis-je personnaliser les paramètres de configuration de PostgreSQL ?

Pool de connexions

Pourquoi des erreurs `prepared statement does not exist` apparaissent-elles via PgBouncer ?

Pourquoi les requêtes échouent-elles avec `cached plan must not change result type` après une migration ?

Pourquoi l’erreur `unsupported startup parameter` apparaît-elle avec PgBouncer ?

Pourquoi les commandes `SET` ne sont-elles pas conservées avec PgBouncer ?

Pourquoi les migrations se bloquent-elles ou n’arrivent-elles pas à libérer un verrou consultatif via PgBouncer ?

Que signifie le paramètre `max_client_conn` dans PgBouncer, et comment se compare-t-il à `max_connections` dans Postgres ?

Fonctionnalités de la base de données

Puis-je créer plusieurs bases de données et schémas ?

Le contrôle d’accès basé sur les rôles (RBAC) est-il pris en charge ?

Mises à niveau

Comment les mises à niveau de version de PostgreSQL sont-elles gérées ?

Migration

Quels outils sont disponibles pour migrer vers ClickHouse Managed Postgres ?

​Monitoring et métriques

​Comment puis-je accéder aux métriques de mon instance ClickHouse Managed Postgres ?

​Sauvegarde et restauration

​Quelles options de sauvegarde sont disponibles ?

​Infrastructure et automatisation

​Quels fournisseurs cloud sont pris en charge ?

​Terraform est-il pris en charge pour ClickHouse Managed Postgres ?

​Extensions et configuration

​Quelles extensions sont prises en charge ?

​Puis-je personnaliser les paramètres de configuration de PostgreSQL ?

​Pool de connexions

​Pourquoi des erreurs prepared statement does not exist apparaissent-elles via PgBouncer ?

​Pourquoi les requêtes échouent-elles avec cached plan must not change result type après une migration ?

​Pourquoi l’erreur unsupported startup parameter apparaît-elle avec PgBouncer ?

​Pourquoi les commandes SET ne sont-elles pas conservées avec PgBouncer ?

​Pourquoi les migrations se bloquent-elles ou n’arrivent-elles pas à libérer un verrou consultatif via PgBouncer ?

​Que signifie le paramètre max_client_conn dans PgBouncer, et comment se compare-t-il à max_connections dans Postgres ?

​Fonctionnalités de la base de données

​Puis-je créer plusieurs bases de données et schémas ?

​Le contrôle d’accès basé sur les rôles (RBAC) est-il pris en charge ?

​Mises à niveau

​Comment les mises à niveau de version de PostgreSQL sont-elles gérées ?

​Migration

​Quels outils sont disponibles pour migrer vers ClickHouse Managed Postgres ?

Monitoring et métriques

Comment puis-je accéder aux métriques de mon instance ClickHouse Managed Postgres ?

Sauvegarde et restauration

Quelles options de sauvegarde sont disponibles ?

Infrastructure et automatisation

Quels fournisseurs cloud sont pris en charge ?

Terraform est-il pris en charge pour ClickHouse Managed Postgres ?

Extensions et configuration

Quelles extensions sont prises en charge ?

Puis-je personnaliser les paramètres de configuration de PostgreSQL ?

Pool de connexions

Pourquoi des erreurs `prepared statement does not exist` apparaissent-elles via PgBouncer ?

Pourquoi les requêtes échouent-elles avec `cached plan must not change result type` après une migration ?

Pourquoi l’erreur `unsupported startup parameter` apparaît-elle avec PgBouncer ?

Pourquoi les commandes `SET` ne sont-elles pas conservées avec PgBouncer ?

Pourquoi les migrations se bloquent-elles ou n’arrivent-elles pas à libérer un verrou consultatif via PgBouncer ?

Que signifie le paramètre `max_client_conn` dans PgBouncer, et comment se compare-t-il à `max_connections` dans Postgres ?

Fonctionnalités de la base de données

Puis-je créer plusieurs bases de données et schémas ?

Le contrôle d’accès basé sur les rôles (RBAC) est-il pris en charge ?

Mises à niveau

Comment les mises à niveau de version de PostgreSQL sont-elles gérées ?

Migration

Quels outils sont disponibles pour migrer vers ClickHouse Managed Postgres ?