Versionamento e Política de Atualização

O PostgreSQL lança grandes releases anualmente com novos recursos e pequenos releases com correções de segurança e bugs. Planeje atualizações antes do EOL. PostgreSQL 18 é o estável atual; 17 permanece em manutenção. Trate atualizações menores como obrigatórias, e as maiores como projetos.

Receita

SELECT version();
SHOW server_version_num;
 
-- Após a atualização, analise para estatísticas do planejador
ANALYZE;

# Atualização menor (mesmo diretório de dados, novos binários)
pg_ctl stop -D $PGDATA
# instale o release de ponto postgresql-18.x
pg_ctl start -D $PGDATA

Quando usar isso: Você define a política da organização para versões suportadas, cadência de patches e janelas de migração principais.

Exemplo de Trabalho

-- Funções auxiliares de verificação de compatibilidade de catálogo após atualização principal
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;

O que isso demonstra:

• server_version_num é comparável como um inteiro em scripts
• Extensões podem precisar de ALTER EXTENSION ... UPDATE após a atualização do servidor
• Índices inválidos sinalizam trabalho de reconstrução após pg_upgrade ou restauração

Mergulho Profundo

Tipos de Release

• Principal (17 para 18): alterações de catálogo, initdb não é necessário se usar pg_upgrade ou replicação lógica.
• Menor (18.3 para 18.4): substituição binária "drop-in", mesmo formato PGDATA.
• EOL: versões não suportadas não recebem correções de segurança.

Caminhos de Atualização

Linha de Base da Política

• Execute o menor mais recente em um major suportado dentro de 30 dias do lançamento.
• Atualização principal dentro de 6 meses após o anúncio EOL do major anterior.
• Teste extensões (pgvector, PostGIS) em staging antes do major de produção.

Armadilhas

• Pular releases menores - CVEs de segurança chegam apenas em releases menores. Correção: Automatize atualizações de apt/yum/dnf ou de imagem mensalmente.
• Atraso na ABI da extensão - PostGIS e pgvector precisam de builds correspondentes por major. Correção: Fixe versões no runbook antes do fim de semana de atualização.
• Estatísticas reiniciadas - Atualizações principais podem invalidar planos até que ANALYZE seja executado. Correção: Agende ANALYZE ou confie nos limites de análise do autovacuum.
• Mistura de versões de replicação - Assinantes podem ser mais novos; publicadores mais antigos com cuidado. Correção: Leia a matriz de compatibilidade de replicação lógica.
• Deriva de bibliotecas do SO - Discrepância entre libpq e servidor causa erros de protocolo estranhos. Correção: Atualize as bibliotecas cliente com o servidor.

Alternativas

FAQs

Relacionados

• Noções Básicas de PostgreSQL - version() e tour do cluster
• Noções Básicas de Instalação - canais de empacotamento
• Noções Básicas de Governança - propriedade do calendário de atualização

Versões da Stack: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x e PostGIS 3.5+.