Arquitectura de Postgres
PostgreSQL es un servidor multiproceso: un postmaster supervisor crea procesos backend por conexión de cliente, mientras que los trabajadores de fondo mantienen la durabilidad y la higiene de la caché. Comprender esta división explica los límites de conexión, el dimensionamiento de la memoria y por qué los reinicios difieren de las recargas.
Receta
-- Ver backends activos y lo que ejecutan
SELECT pid, usename, application_name, state, wait_event_type, query
FROM pg_stat_activity
WHERE backend_type = 'client backend'
ORDER BY state, pid;# Recargar la configuración sin desconectar (muchas GUCs)
pg_ctl reload -D /var/lib/postgresql/18/main
# Reinicio completo recicla el postmaster y todos sus hijos
pg_ctl restart -D /var/lib/postgresql/18/mainCuándo usar esto: Necesitas razonar sobre conexiones, memoria, puntos de control o por qué una configuración requiere un reinicio.
Ejemplo práctico
-- Indicación de la tasa de generación de WAL (bytes por ciclo de punto de control)
SELECT checkpoints_timed, checkpoints_req,
wal_bytes, buffers_checkpoint
FROM pg_stat_bgwriter;
-- Ratio de aciertos de búferes compartidos (a nivel de base de datos)
SELECT sum(blks_hit)::float / nullif(sum(blks_hit) + sum(blks_read), 0) AS cache_hit_ratio
FROM pg_stat_database;Lo que esto demuestra:
pg_stat_activitysepara los backends de cliente de los trabajadores de fondo.pg_stat_bgwriterexpone el volumen de puntos de control y WAL.- El ratio de aciertos de búfer aproxima cuántas lecturas provienen de
shared_buffersfrente al disco. - Recarga frente a reinicio es una distinción operativa ligada al ciclo de vida del postmaster.
Inmersión profunda
Modelo de procesos
- Postmaster escucha en el puerto y crea un nuevo backend por cada conexión TCP (a menos que se use pooling).
- Background writer (escritor de fondo) es el que vacía las páginas sucias; checkpointer finaliza los segmentos de WAL y avanza los puntos de rehacer.
- WAL writer (escritor de WAL) agrupa los fsyncs de los búferes de WAL; autovacuum launcher (lanzador de autovacuum) programa los trabajadores de vacuum/analyze de tablas.
- Los trabajadores de Stats collector (recolector de estadísticas) y logical replication (replicación lógica) aparecen como tipos de fondo adicionales.
Disposición de memoria
- shared_buffers contiene páginas de datos cacheadas compartidas por todos los backends.
- Cada backend tiene work_mem (por nodo de ordenación/hash) y maintenance_work_mem (para VACUUM, CREATE INDEX).
- effective_cache_size es una pista para el planificador sobre la caché de páginas del SO, no sobre la RAM asignada.
Ruta de durabilidad
- El backend modifica la página del búfer compartido e inserta un registro WAL.
- El WAL se vacía en disco (el commit depende de synchronous_commit).
- El punto de control escribe las páginas sucias; la recuperación ante fallos rehace el WAL desde el último punto de control.
Trampas
- Un backend por conexión - Sin PgBouncer, 500 hilos de aplicación pueden significar 500 procesos de Postgres... Solución: Agrupar en la aplicación o con PgBouncer; ajustar
max_connectionsadecuadamente. - work_mem se multiplica - Diez ordenaciones paralelas en una consulta pueden usar 10 veces
work_mem... Solución: Limitarwork_mem; vigilarEXPLAINpara nodos de Ordenación/Hash. - La recarga no aplica todo - Los cambios en
shared_buffersrequieren un reinicio... Solución: Comprobar elcontextdepg_settingsantes de asumir que la recarga funciona. - Transacción inactiva prolongada - Las transacciones abiertas bloquean el vacuum y retienen versiones de filas... Solución: Establecer
idle_in_transaction_session_timeout. - Autovacuum no es opcional - Las actualizaciones/eliminaciones dejan tuplas muertas hasta que se ejecuta vacuum... Solución: Monitorizar
pg_stat_user_tables.n_dead_tup.
Alternativas
| Alternativa | Usar cuando | No usar cuando |
|---|---|---|
| Agrupador de conexiones (PgBouncer) | Muchas conexiones de aplicación de corta duración | Necesitas sentencias preparadas fijadas a un backend en modo transacción |
| Postgres gestionado (RDS, Cloud SQL) | El equipo de operaciones quiere que se encarguen de parches y copias de seguridad | Necesitas extensiones personalizadas o ajuste del kernel |
| Réplicas de lectura | Cargas de trabajo con muchas lecturas fuera del primario | La replicación síncrona añade latencia al commit |
Preguntas frecuentes
¿Cuál es la diferencia entre recargar y reiniciar?
La recarga relee postgresql.conf para muchos parámetros. El reinicio recicla todos los procesos y es necesario para las GUCs relacionadas con la memoria.
¿Cuántas conexiones puede manejar Postgres?
Depende de la RAM y la carga de trabajo. Cientos de conexiones inactivas son baratas; cientos de consultas activas no lo son. Agrupa agresivamente.
¿Dónde se almacenan los datos en disco?
El directorio de datos (PGDATA) contiene archivos heap, WAL y catálogos. Usa tablespaces solo cuando necesites rutas de almacenamiento separadas.
¿Utiliza PostgreSQL hilos?
No para los backends. Los trabajadores de consulta paralela son procesos separados creados para una única sentencia.
¿Qué sucede en caso de fallo?
Al arrancar, Postgres rehace el WAL desde el último punto de control y luego acepta conexiones.
Relacionados
- Conceptos básicos de PostgreSQL - recorrido por clúster, esquema y tablas
- Conceptos básicos de instalación - paquetes y disposición del directorio de datos
- Conceptos básicos de transacciones - MVCC y WAL desde la vista de sesión
- Conceptos básicos de agrupación de conexiones - reducción del número de backends
Versiones de la pila: Esta página se escribió para PostgreSQL 18.4 (estable 18, mantenimiento 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x y PostGIS 3.5+.