监控与指标
如何访问我的 ClickHouse Managed Postgres 实例指标？
你可以直接在 ClickHouse Cloud 控制台中，进入 ClickHouse Managed Postgres 实例的 Monitoring 选项卡，监控 CPU、内存、IOPS 和存储使用情况。 此外，你还可以在 Query Insights 选项卡中查看 Query Performance Insights，对查询进行详细分析。备份与恢复
有哪些可用的备份选项？
ClickHouse Managed Postgres 提供每日自动备份和持续 WAL 归档，支持将数据库恢复到 7 天保留期内的任意时间点。备份存储在对象存储中。 有关备份频率、保留期以及如何执行时间点恢复的完整信息，请参阅 备份与恢复 文档。基础设施与自动化
支持哪些云提供商？
ClickHouse Managed Postgres 目前已在 AWS 上以 Public Beta 形式提供，GCP 则处于私有预览阶段。您可以在此处加入 GCP 私有预览的候补名单，并阅读公告了解更多信息。详情请参见支持的云提供商。ClickHouse Managed Postgres 是否支持 Terraform？
支持。您可以使用 ClickHouse Terraform provider 的clickhouse_postgres_service 资源来创建和管理 ClickHouse Managed Postgres 服务。详见 Terraform 参考。您也可以使用 ClickHouse Cloud 控制台或 OpenAPI 创建和管理您的实例。
扩展和配置
支持哪些扩展？
ClickHouse Managed Postgres 提供超过 90 个 PostgreSQL 扩展，包括 PostGIS、pgvector、pg_cron 等热门扩展，以及更多其他扩展。有关可用扩展的完整列表和安装说明，请参阅 扩展 文档。我可以自定义 PostgreSQL 配置参数吗？
可以，您可以通过控制台中的 Settings 选项卡修改 PostgreSQL 和 PgBouncer 的配置参数。有关可用参数及其修改方法的详细信息，请参阅 Settings 文档。连接池
为什么通过 PgBouncer 连接时会出现 prepared statement does not exist 错误？
ClickHouse Managed Postgres 以 事务池化 (transaction pooling) 模式运行 PgBouncer。在此模式下，后端 Postgres 连接仅在单个事务期间分配给您的客户端，事务结束后即归还连接池——同一客户端的下一个事务可能会被分配到另一个后端连接上。
PgBouncer 会跟踪 协议级预处理语句，大多数驱动程序通过扩展查询协议 (Parse、Bind 和 Execute 消息) 发送这类语句。当某条语句在尚未准备过它的后端上执行时，PgBouncer 会先在该后端上完成预处理。每个后端连接最多保留 max_prepared_statements 条此类语句，默认值为 200。因此，大多数驱动程序使用默认设置即可通过 PgBouncer 正常工作。
以下情况无法通过 PgBouncer 正常工作：
- SQL 级预处理语句。 PgBouncer 不会跟踪以 SQL 形式发送的
PREPARE和EXECUTE，因此EXECUTE可能会被发送到从未执行过相应PREPARE的后端上。 - 使用 SQL
DEALLOCATE释放语句。 PgBouncer 会在后端对语句进行重命名，因此按客户端语句名称执行的DEALLOCATE会失败。如果在事务内执行，该操作会导致事务中止，后续语句将报错current transaction is aborted。基于 libpq 17 或更高版本构建的驱动程序改用协议级Close消息释放语句，PgBouncer 可以正确处理这种方式。 - 分多次往返发送的未命名语句。 某些驱动程序模式会在一次往返中发送未命名语句的
Parse，在下一次往返中再发送其Bind。PgBouncer 可能会将第二次往返分配到另一个后端上执行，从而报错unnamed prepared statement does not exist，甚至在无任何报错的情况下执行另一个客户端的语句并返回其结果。
- 突发大量
prepared statement does not exist错误，尤其是在回填数据或高并发写入期间 - 插入操作看似”静默失败”——语句报错后驱动程序进行重试，最终某个批次可能只被部分写入，甚至被丢弃
- 某条语句被释放后，事务失败并报
current transaction is aborted错误 - 返回的行属于另一个查询
如果您的工作负载依赖 SQL 级别的
PREPARE，请直接连接 PostgreSQL (端口 5432) ，而不要经由 PgBouncer 连接池器。有关如何在池化端点与直连端点之间进行选择，请参见 Connection。
为什么迁移后查询会因 cached plan must not change result type 而失败？
PgBouncer 会在其 Postgres 连接上保留预处理语句，并对相同的 SQL 文本复用这些语句。如果 schema 变更改变了某个查询所返回列的类型 (例如从 integer 改为 bigint) ，该查询通过 PgBouncer 执行时就会持续报错 cached plan must not change result type。即使从新的客户端连接发起，该查询依然会失败，直到 PgBouncer 替换其 Postgres 连接为止。某些驱动程序则会按过时的结果类型解码，在不报错的情况下返回错误的值。而如果通过直接连接，每个连接最多失败一次，随后便会恢复。
要恢复正常，请关闭 PgBouncer 针对该数据库的 Postgres 连接，PgBouncer 随后会建立新的连接。由于 PgBouncer 在本地连接 Postgres，其连接没有 client_addr。请通过直接连接 (端口 5432) ，以应用程序连接时所用的同一用户身份运行以下语句。该语句仅终止 PgBouncer 为您的应用程序用户建立的连接，因此当时正通过 PgBouncer 运行的事务会失败，而直接连接不受影响：
prepare: :unnamed 的 Postgrex，以及启用了 cache_describe 的 pgx。
为什么通过 PgBouncer 连接时会出现 unsupported startup parameter 错误？
对于无法在其连接池中各个 Postgres 连接上一致生效的连接时设置，PgBouncer 会直接拒绝，并报错 FATAL: unsupported startup parameter: ... 或 unsupported startup parameter in options: ...。常见情况如下：
extra_float_digits：pgjdbc 42.7.4 及更早版本 (例如搭配 Spring Boot 3 使用时) 以及 sqlx 会在每次建立连接时发送此参数。请将 pgjdbc 升级到 42.7.5 或更高版本；如使用 sqlx，请在PgConnectOptions上设置extra_float_digits(None)。- 连接字符串中的
search_path及其他设置：例如 JDBC URL 中的currentSchema、Npgsql 连接字符串中的Search Path、options=-c ...，或 Django 的OPTIONS["options"]。请改用ALTER ROLE ... SET或ALTER DATABASE ... SET设置默认值，或在事务内使用SET LOCAL，也可以绕过 PgBouncer 直接连接数据库。
application_name 和 TimeZone 均受支持。
为什么通过 PgBouncer 执行的 SET 命令无法持续生效？
在事务池化模式下，会话级别的 SET 作用于执行它的 Postgres 连接，而不是你的客户端。你的客户端后续发起的事务可能会在没有该设置的其他连接上运行，而其他客户端则可能恰好使用带有该设置的连接。SET ROLE 也是如此，因此你切换到的角色可能会作用于其他客户端的查询。对于依赖会话状态的工作负载，请在事务内使用 SET LOCAL，或通过 ALTER ROLE ... SET 或 ALTER DATABASE ... SET 设置默认值，也可以直接连接数据库。
为什么通过 PgBouncer 执行迁移时会挂起或无法释放咨询锁？
许多迁移工具会获取会话级咨询锁，确保同一时间只有一个迁移在运行，随后再用一条单独的语句释放该锁。经由 PgBouncer 时，释放语句可能在另一个 Postgres 连接上执行，导致锁残留在连接池中的某个连接上。此后的迁移便会一直等待，或因failed to release advisory lock 等错误而失败，即使改用直接连接也是如此。使用会话咨询锁的工具包括 golang-migrate、sqlx、Kysely 的 Migrator、Rails、配置了 transactional-lock=false 的 Flyway，以及配置了 migration_lock: :pg_advisory_lock 的 Ecto。
请通过直接连接 (端口 5432) 运行迁移。泄漏的锁由空闲会话持有，而仍在运行的迁移则由活跃会话持有其锁。要清除泄漏的锁，请同样通过直接连接，仅终止数据库中持有咨询锁的空闲会话：
PgBouncer 中的 max_client_conn 设置是什么意思？它与 Postgres 中的 max_connections 有什么关系？
它们控制的是不同的对象：
- Postgres
max_connections限制的是 PostgreSQL 自身的 后端 连接数。这才是成本较高的那个限制——每个 后端 都会占用内存和一个进程槽位。 - PgBouncer
max_client_conn限制的是连接池器中可同时打开的 客户端 连接数。PgBouncer 会将大量客户端连接复用到一组小得多的 后端 连接上。
max_connections 设置为 500 的实例，在连接池器处可接受 2500 个客户端连接。如果你在连接池器这一层看到连接错误，那么相比达到醒目的客户端连接上限，更有可能是触及了每个连接池的 后端 限制 (default_pool_size，或每个数据库的 max_db_connections) 。
要查看你的实例的配置值，请通过 PgBouncer (端口 6432) 连接到特殊的 pgbouncer 数据库，并运行 SHOW CONFIG：
数据库功能
我可以创建多个数据库和 schema 吗？
可以。ClickHouse Managed Postgres 提供完整的 PostgreSQL 原生功能，包括在单个实例中支持多个数据库和 schema。您可以使用标准的 PostgreSQL 命令来创建和管理数据库及 schema。是否支持基于角色的访问控制 (RBAC) ？
您对自己的 ClickHouse Managed Postgres 实例拥有完整的 superuser 访问权限，因此可以使用标准的 PostgreSQL 命令创建角色并管理权限。计划于今年推出与控制台集成的增强 RBAC 功能。
升级
PostgreSQL 版本升级是如何处理的？
无论是次要版本升级还是主版本升级，都是通过故障转移完成的，通常只会造成几秒钟的停机。您可以配置计划升级，以控制在哪些日期及哪个两小时 UTC 时段内应用升级。完整详情请参阅升级文档。迁移
可用于迁移到 ClickHouse Managed Postgres 的工具有哪些？
ClickHouse Managed Postgres 支持多种迁移方式：- pg_dump 和 pg_restore：适用于较小的数据库或一次性迁移。请参阅 pg_dump 和 pg_restore 指南。
- 逻辑复制：适用于需要尽量减少停机时间的大型数据库。请参阅 逻辑复制 指南。
- PeerDB：适用于从其他 Postgres 源进行基于 CDC 的复制。请参阅 PeerDB 迁移 指南。
全托管迁移体验即将推出。