¿Cómo puedo acceder a las métricas de mi instancia de Managed Postgres?
Query Performance Insights, con análisis detallado de consultas, estará disponible próximamente.
Copia de seguridad y recuperación
¿Qué opciones de copia de seguridad están disponibles?
Infraestructura y automatización
Extensiones y configuración
¿Qué extensiones son compatibles?
¿Puedo personalizar los parámetros de configuración de PostgreSQL?
Si necesitas un parámetro que actualmente no está disponible, ponte en contacto con soporte para solicitarlo. ¿Por qué veo errores de prepared statement does not exist al usar PgBouncer?
PREPARE (o Parse en la consulta extendida). Cuando el Execute correspondiente termina en un backend distinto, aparecen errores como:
ERROR: prepared statement "..." does not exist
ERROR: unnamed prepared statement does not exist
- Ráfagas de errores
prepared statement does not exist, especialmente durante backfills o escrituras con alta concurrencia
- Inserciones que parecen “fallar en silencio”: la sentencia da error, el driver reintenta y un lote puede terminar aplicándose solo parcialmente o descartándose
- Valores devueltos con el tipo incorrecto (por ejemplo, una columna
BIGINT decodificada como un patrón de bits float64): esto sucede cuando un plan del lado del cliente almacenado en caché reutiliza códigos de tipo o formato obsoletos frente a un backend al que nunca se le envió el Parse correspondiente
Solución: desactive las sentencias preparadas del lado del servidor en su driver. La opción exacta depende de su biblioteca cliente:
| Driver | Configuración |
|---|
| pgx (Go) | statement_cache_capacity=0 y default_query_exec_mode=exec (o simple_protocol) |
| psycopg3 (Python) | prepare_threshold=None |
| asyncpg (Python) | statement_cache_size=0 |
| JDBC (Java) | prepareThreshold=0 |
| node-postgres / pg (Node.js) | No pase un name a query() (las consultas con nombre se preparan en el servidor) |
¿Qué significa el parámetro “max_client_conn” en PgBouncer y cómo se relaciona con max_connections en Postgres?
- Postgres
max_connections limita la cantidad de conexiones de backend a PostgreSQL. Este es el número costoso: cada backend consume memoria y un slot de proceso.
- PgBouncer
max_client_conn limita la cantidad de conexiones de cliente que pueden estar abiertas al mismo tiempo hacia el pooler. PgBouncer multiplexa esa gran cantidad de conexiones de cliente sobre un conjunto mucho más pequeño de conexiones de backend.
Una instancia típica de Managed Postgres está configurada para que PgBouncer acepte aproximadamente 10× más conexiones de cliente que backends de Postgres (por ejemplo, 5000 clientes / 500 backends). Si ve errores de conexión en el pooler, es mucho más probable que esté alcanzando un límite de backend por pool (default_pool_size) que el límite general de clientes.
Capacidades de la base de datos
¿Puedo crear varias bases de datos y esquemas?
¿Se admite el control de acceso basado en roles (RBAC)?
Está previsto incorporar este año funciones avanzadas de RBAC con integración en consola.
¿Cómo se gestionan las actualizaciones de versión de PostgreSQL?
- pg_dump and pg_restore: Para bases de datos más pequeñas o migraciones puntuales. Consulta la guía de pg_dump and pg_restore.
- Logical replication: Para bases de datos más grandes que requieren un tiempo de inactividad mínimo. Consulta la guía de Replicación lógica.
- PeerDB: Para la replicación basada en CDC desde otras fuentes de Postgres. Consulta la guía de Migración con PeerDB.
Próximamente estará disponible una experiencia de migración totalmente gestionada.
