Repositório RPM do PostgreSQL ganha site mais simples de configurar

Quem sobe PostgreSQL↳PostgreSQL11 conteúdosPostgreSQL via SSL com GolangData · abr 20195 itens legais sobre data types do PostgreSQLData · mar 20195 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → em RHEL, Rocky Linux↳Linux34 conteúdosKali Linux em um Servidor VPS: como, quando e por que usar?DevSecOps · dez 2024Construindo um Windows Service ou Linux Daemon com Worker Service & .NET Core – Parte 2Dev (Back & Front) · jul 2020Criando uma WebApi utilizando .NET, Linux e VSCodeDev (Back & Front) · ago 2019Ver tudo em DevSecOps →, AlmaLinux, Fedora, SLES ou openSUSE via pacote oficial conhece o ritual: entrar em yum.postgresql.org ou zypp.postgresql.org, navegar por páginas de documentação até achar a combinação certa de distribuição, versão do sistema operacional, arquitetura e versão major do PostgreSQL, copiar a URL do RPM do repositório e só então instalar. Nesta segunda-feira, 28 de setembro de 2026, Devrim Gündüz, mantenedor do PGDG (PostgreSQL Global Development Group) para pacotes RPM e Principal Systems Engineer na EDB, publicou em seu blog pessoal no Planet PostgreSQL que esse fluxo foi simplificado: a página inicial dos dois sites agora resolve a busca em um único formulário.

O que mudou na prática

Segundo o próprio Gündüz, o usuário seleciona sistema operacional, versão, arquitetura e versão do PostgreSQL diretamente na página inicial, e o site devolve as instruções já prontas para copiar e colar no terminal. Na descrição dele: "Users no longer have to navigate through pages on the website. Instead, the front page has a clear layout and easy-to-follow instructions." Isso elimina a etapa manual de garimpar, em meio à documentação, qual RPM do repositório corresponde exatamente à combinação de EL9 x86_64 com PostgreSQL 17, por exemplo, tarefa que historicamente gerava instalações com repositório errado, GPG key desatualizada ou, pior, versão major do PostgreSQL diferente da planejada para o ambiente.

O anúncio também traz um recurso novo: um botão "copy link", que gera uma URL customizável apontando para a combinação de opções escolhida. Essa URL pode ser colada em posts de blog, documentação interna ou, o que interessa mais a quem automatiza infraestrutura, referenciada e parseada por scripts de provisionamento. Isso significa que playbooks Ansible, receitas Chef, módulos Terraform ou Dockerfiles que hoje fixam manualmente a URL do RPM de repositório (algo como o pacote pgdg-redhat-repo ou pgdg-sles-repo, seguindo a convenção já conhecida do PGDG) passam a ter uma fonte de verdade única e versionável, em vez de depender de alguém copiar a URL certa uma vez e replicá-la de memória em outros projetos.

Por que o RPM errado é um problema real de produção

Para quem trabalha com bancos de dados, a diferença entre instalar o repositório certo e o repositório errado não é cosmética. O PGDG mantém repositórios separados por versão major do PostgreSQL e por versão do sistema operacional, exatamente para evitar que o gerenciador de pacotes resolva dependências contra a versão errada de bibliotecas do sistema. Um RPM de repositório apontando para o EL8 instalado num host EL9, ou um repositório de PostgreSQL 16 usado num cluster planejado para rodar 17, não necessariamente falha na hora da instalação: às vezes o erro só aparece depois, em um pg_upgrade mal-sucedido, num plugin de extensão que não compila contra a versão do libpq errada, ou numa réplica que se recusa a subir porque o binário não bate com o PG_VERSION do diretório de dados. Reduzir a superfície de erro humano nessa escolha inicial tem, portanto, efeito direto sobre a integridade do ambiente antes mesmo de qualquer query ser executada.

O anúncio também menciona que as instruções para o repositório de pacotes extra (extra packages) e para o repositório non-free ficaram mais claras. Esses dois repositórios concentram extensões e drivers que não entram no pacote core do PostgreSQL por licenciamento ou por não fazerem parte do projeto oficial, e que costumam ser fonte de confusão sobre qual repositório habilitar para obter, por exemplo, um driver de conectividade específico ou uma extensão de terceiros empacotada pelo próprio PGDG.

Um dia de vários ajustes no mesmo repositório

O anúncio do novo site não é um evento isolado. No mesmo dia, 28 de setembro de 2026, Gündüz publicou também que os RPMs dos repositórios para RHEL, Rocky Linux e AlmaLinux passam a seguir a versão minor do sistema operacional, e que o repositório do PostgreSQL chegou ao Amazon Linux 2023. Juntos, os três anúncios do mesmo dia desenham um movimento de amadurecimento da distribuição via RPM: mais precisão sobre qual build corresponde a qual minor da distro hospedeira, mais uma plataforma cloud coberta (Amazon Linux 2023, comum em EC2 e em imagens gerenciadas na AWS) e, agora, uma interface que reduz o atrito de descobrir os comandos certos para tudo isso. Vale registrar que o próprio PGDG já vinha nessa trilha há tempo: o blog lista, em meses anteriores, suporte a openSUSE Leap 16.0 em março de 2026 e melhorias na instalação em SLES 15 desde fevereiro de 2024, sinal de que a cobertura de distribuições RPM é uma frente contínua, não um esforço pontual.

O que a reforma não resolve

O novo site facilita achar o comando certo, mas não elimina responsabilidades que continuam sendo do administrador. A importação da chave GPG do PGDG antes de confiar no repositório continua sendo um passo manual, e nenhum time de infraestrutura deveria pular a validação dessa assinatura antes de apontar produção para um repositório externo, por mais confiável que seja a fonte. O formulário também não substitui a decisão de pin de versão: em ambientes de produção, é prática recomendada travar a versão minor exata do PostgreSQL no arquivo de configuração do dnf ou do zypper (via exclude ou versionlock), evitando que um dnf update de rotina suba a versão minor sem uma janela de manutenção planejada. Isso vale ainda mais depois do ajuste anunciado no mesmo dia sobre RPMs seguirem a versão minor do sistema operacional: quanto mais granular fica o pareamento entre pacote e distro, mais importa automatizar essa checagem em vez de confiar em memória.

Outro ponto: a novidade cobre apenas os ecossistemas YUM (Red Hat, Rocky, AlmaLinux, Fedora, Amazon Linux) e ZYPP (SUSE, openSUSE). Quem roda PostgreSQL via APT em Debian ou Ubuntu não é afetado por essa mudança específica, já que o repositório APT do PGDG é mantido separadamente. E, para quem já tem pipelines de provisionamento maduros com a URL do repositório fixada em variável de ambiente ou em um módulo interno de infraestrutura como código, o ganho imediato é menor: o valor concentra-se em quem ainda configura hosts manualmente, em quem sobe ambientes de teste com frequência ou em quem está desenhando pela primeira vez a automação de um cluster PostgreSQL sobre RPM.

Ainda assim, para uma peça de infraestrutura tão central quanto o repositório de pacotes de um banco de dados relacional amplamente usado em produção, reduzir a chance de erro na primeira etapa (a escolha do repositório certo) é uma melhoria de governança discreta, mas com efeito direto sobre a confiabilidade de tudo que vem depois: instalação, upgrade e, eventualmente, restauração de backup em uma versão compatível.

Fonte: Planet PostgreSQL