Ruta de Actualización de Extensiones

Las versiones de las extensiones se mueven independientemente de las versiones mayores de Postgres. Planifique las actualizaciones de paquetes del sistema operativo, ALTER EXTENSION UPDATE y las pruebas de regresión como una única ventana de cambio, especialmente para pgvector y PostGIS.

Receta

-- Comprobar la versión actual frente a la versión de destino
SELECT extname, extversion
FROM pg_extension
WHERE extname = 'vector';
 
SELECT name, default_version
FROM pg_available_extensions
WHERE name = 'vector';
 
-- Aplicar scripts de actualización disponibles
ALTER EXTENSION vector UPDATE TO '0.8.0';
 
-- Verificar
SELECT extname, extversion FROM pg_extension WHERE extname = 'vector';

Cuándo usar esto: Después de aplicar parches a Postgres, desplegar nuevos paquetes de extensiones o antes de construir índices HNSW que requieran una versión mínima de pgvector.

Ejemplo de Trabajo

-- Runbook seguro de actualización (ejecutar primero en staging)
BEGIN;
 
-- 1) Inventario de instantánea
CREATE TEMP TABLE ext_before AS
SELECT extname, extversion FROM pg_extension;
 
-- 2) Actualizar una extensión
ALTER EXTENSION postgis UPDATE;
 
-- 3) Comparar
SELECT b.extname,
       b.extversion AS before_version,
       e.extversion AS after_version
FROM ext_before b
JOIN pg_extension e ON e.extname = b.extname
WHERE b.extversion IS DISTINCT FROM e.extversion;
 
-- 4) Prueba de humo
SELECT PostGIS_Version();
SELECT ST_Distance(
  ST_MakePoint(-73.9857, 40.7484)::geography,
  ST_MakePoint(-118.2437, 34.0522)::geography
) AS nyc_to_la_meters;
 
COMMIT;

Lo que esto demuestra:

• El inventario antes y después evita omisiones silenciosas
• ALTER EXTENSION UPDATE sin TO aplica el script disponible más reciente
• Las consultas de prueba de humo funcionales detectan desajustes tempranos de SONAME rotos
• La transacción envuelve el cambio de metadatos; las bibliotecas del SO deben coincidir ya

Análisis Profundo

Mecánicas de Actualización

1. Capa de SO / paquete - Instalar postgresql-18-postgis-3.5 (o equivalente del proveedor) en cada nodo.
2. Capa de base de datos - ALTER EXTENSION name UPDATE [TO 'version'] ejecuta scripts de migración SQL en EXTENSION(name)/.
3. Capa de índice - Algunas actualizaciones requieren REINDEX (cambios en las clases de op de índice de pgvector). Lea las notas de la versión.

-- Listar los scripts de ruta de actualización incluidos con la extensión
SELECT version, relocatable
FROM pg_available_extension_versions
WHERE name = 'vector'
ORDER BY version;

Versiones Menores vs. Mayores de Extensiones

Clústeres Multi-Nodo

• Primero la primaria - Aplicar paquetes y ALTER EXTENSION en la primaria.
• Réplicas - Los paquetes deben existir antes de que la replicación reproduzca consultas dependientes de extensiones.
• Patroni - Sincronización rodante de paquetes del SO, luego ALTER EXTENSION controlado durante la ventana de mantenimiento.
• Nube gestionada - El proveedor actualiza el catálogo de extensiones; usted aún ejecuta ALTER EXTENSION en cada base de datos.

Realidad del Rollback

No existe ALTER EXTENSION DOWNGRADE. El rollback significa restaurar desde una copia de seguridad o recrear índices después de reinstalar paquetes más antiguos (alto riesgo). Pruebe las actualizaciones en un clon de instantánea.

Trampas Comunes

• Desajuste binario/SQL - Un nuevo script SQL con un archivo .so antiguo causa fallos en tiempo de ejecución. Solución: Actualice los paquetes en todos los nodos antes de ALTER EXTENSION.
• Reindexación de larga duración - La reconstrucción del índice HNSW de pgvector bloquea o consume I/O. Solución: REINDEX CONCURRENTLY donde sea compatible; programe fuera de horas pico.
• Bases de datos olvidadas - Extensión actualizada en appdb pero no en analytics. Solución: Iterar sobre todas las bases de datos: \l + ALTER EXTENSION por base de datos.
• Nombres de clases de op que rompen - Las consultas del cliente hacen referencia a clases de op antiguas. Solución: Busque en la base de código las definiciones de índices; migre en fases de expansión-contracción.
• Extras de topología de PostGIS - Extensiones separadas (postgis_topology) necesitan su propia UPDATE. Solución: Inventar todas las filas postgis* en pg_extension.
• Deriva de replicación lógica - El suscriptor no tiene la versión de la extensión. Solución: Haga coincidir las versiones de las extensiones antes de suscribirse a publicaciones con muchos DDL.

Alternativas

Preguntas Frecuentes

Relacionado

• Conceptos Básicos de Extensiones - instalar y precargar
• Extensiones Confiables vs. No Confiables - revisión de seguridad
• Índices IVFFlat vs HNSW - implicaciones de la reconstrucción de índices
• Flyway y Liquibase - automatización de migraciones
• Mejores Prácticas para Extensiones - fijar versiones en IaC

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