Versionado y Política de Actualización

PostgreSQL lanza versiones mayores anualmente con nuevas funcionalidades y versiones menores con correcciones de seguridad y errores. Planifica las actualizaciones antes de la fecha de fin de vida (EOL). PostgreSQL 18 es la versión estable actual; la 17 permanece en mantenimiento. Considera las actualizaciones menores como obligatorias y las mayores como proyectos.

Receta

SELECT version();
SHOW server_version_num;
 
-- Después de la actualización, ejecuta ANALYZE para las estadísticas del planificador
ANALYZE;

# Actualización menor (mismo directorio de datos, binarios nuevos)
pg_ctl stop -D $PGDATA
# instala el punto de lanzamiento postgresql-18.x
pg_ctl start -D $PGDATA

Cuándo usar esto: Cuando establezcas la política de la organización para versiones soportadas, la cadencia de parches y las ventanas de migración importantes.

Ejemplo Práctico

-- Ayudantes para la comprobación de compatibilidad del catálogo después de una actualización mayor
SELECT extname, extversion FROM pg_extension ORDER BY 1;
 
SELECT count(*) AS invalid_indexes
FROM pg_index i
JOIN pg_class c ON c.oid = i.indexrelid
WHERE NOT i.indisvalid;

Lo que esto demuestra:

• server_version_num se puede comparar como un entero en scripts.
• Las extensiones pueden necesitar ALTER EXTENSION ... UPDATE después de la actualización del servidor.
• Los índices inválidos indican trabajo de reconstrucción después de pg_upgrade o restauración.

Profundización

Tipos de Lanzamiento

• Mayor (17 a 18): cambios en el catálogo, initdb no es necesario si se usa pg_upgrade o replicación lógica.
• Menor (18.3 a 18.4): reemplazo binario directo, mismo formato PGDATA.
• EOL (Fin de Vida): las versiones no soportadas no reciben correcciones de seguridad.

Rutas de Actualización

Base de la Política

• Ejecuta la última versión menor de la versión mayor soportada dentro de los 30 días posteriores a su lanzamiento.
• Actualización mayor dentro de los 6 meses posteriores al anuncio de EOL de la versión mayor anterior.
• Prueba las extensiones (pgvector, PostGIS) en staging antes de la actualización mayor en producción.

Errores Comunes

• Omitir versiones menores: Las CVE de seguridad solo se incluyen en las versiones menores. Solución: Automatiza las actualizaciones de apt/yum/dnf o de imágenes mensualmente.
• Retraso en la ABI de extensiones: PostGIS y pgvector necesitan compilaciones coincidentes por cada versión mayor. Solución: Fija las versiones en el runbook antes del fin de semana de actualización.
• Estadísticas reiniciadas: Las actualizaciones mayores pueden invalidar los planes hasta que se ejecute ANALYZE. Solución: Programa ANALYZE o confía en los umbrales de análisis de autovacuum.
• Mezcla de versiones de replicación: Los suscriptores pueden ser más nuevos; los publicadores más antiguos con cuidado. Solución: Lee la matriz de compatibilidad de replicación lógica.
• Deriva de bibliotecas del SO: La discrepancia entre libpq y el servidor causa errores de protocolo extraños. Solución: Actualiza las bibliotecas cliente junto con el servidor.

Alternativas

Preguntas Frecuentes

Relacionados

• Conceptos Básicos de PostgreSQL - version() y recorrido del clúster
• Conceptos Básicos de Instalación - canales de empaquetado
• Conceptos Básicos de Gobernanza - propiedad del calendario de actualizaciones

Versiones de Stack: Esta página fue escrita para PostgreSQL 18.4 (estable 18, mantenimiento 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, y PostGIS 3.5+.