PostgreSQL 19 traz pg_stat_recovery e leitura de WAL em backups tar

O engenheiro Pavel Luzanov, da Postgres↳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 → Professional, publicou no Planet PostgreSQL a terceira parte (5.3) da série que acompanha o CommitFest de março de 2026 do PostgreSQL 19, desta vez cobrindo os módulos DBA3 e DBS dos cursos da empresa. O recorte é claramente operacional: backup, recovery, replicação e controle de acesso, a rotina de quem segura produção no plantão. Nenhuma dessas mudanças é cosmética; todas mexem em como o DBA verifica, diagnostica e audita o que o banco está fazendo.

pg_verifybackup e pg_waldump agora leem tar direto

Até esta leva de commits (b15c1513984, b3cf461b3cf), analisar WAL de um backup empacotado em tar exigia extrair o arquivo antes. Agora pg_verifybackup e pg_waldump leem e interpretam o WAL direto de dentro do .tar, sem passo intermediário. Isso elimina um gargalo real em pipelines de backup: no exemplo da própria fonte, um pg_basebackup --format=tar gerou um base.tar de cerca de 6,2 GB e um pg_wal.tar de apenas cerca de 16 MB, e verificar a integridade desse backup significava descompactar tudo antes de rodar a checagem.

O fluxo fica mais direto:

$ pg_basebackup --pgdata=. --format=tar
$ pg_verifybackup .
backup successfully verified

Para acompanhar essa mudança, pg_verifybackup ganha a opção --wal-path, que substitui --wal-directory (ainda suportada, mas marcada como obsoleta). Em termos práticos, isso significa menos espaço em disco temporário e menos tempo de janela de verificação em rotinas de backup que já usam tar como formato padrão, algo comum em storage de objeto e em scripts de arquivamento para S3 ou equivalente.

pg_stat_recovery: uma view só para o estado de recovery

O commit 01d485b142e introduz a view pg_stat_recovery, consultável no processo de startup de uma réplica em replicação física. Antes, as mesmas informações existiam espalhadas por funções do sistema; agora ficam reunidas numa única linha:

SELECT * FROM pg_stat_recovery\gx
-[ RECORD 1 ]------------+------------------------------
promote_triggered | f
last_replayed_read_lsn | F/2F000028
last_replayed_end_lsn | F/2F000060
last_replayed_tli | 1
replay_end_lsn | F/2F000060
replay_end_tli | 1
recovery_last_xact_time |
current_chunk_start_time | 2026-09-08 13:55:36.859622+03
pause_state | not paused

Fora de recovery (no primário, por exemplo), a view simplesmente não retorna linhas, o que já serve como teste rápido de papel do servidor. Para quem escreve scripts de monitoramento, isso elimina a necessidade de combinar pg_last_wal_replay_lsn(), pg_is_in_recovery() e outras funções avulsas numa única query customizada: agora é uma consulta, um ponto de verdade.

psql indica se você está numa réplica

Um dos erros mais caros em operação de banco é rodar um comando de escrita pensando que está no primário quando, na verdade, a sessão está numa réplica (ou vice-versa, ao testar failover). O commit dddbbc253b9 resolve isso com o novo escape %i em PROMPT1/PROMPT2, que mostra standby ou primary conforme o estado de in_hot_standby:

\set PROMPT1 [%i]:PROMPT1
[primary]postgres@postgres(19.0)=#

Ao trocar de conexão, o prompt muda sozinho para [standby]. É um detalhe pequeno, mas que importa especialmente quando a string de conexão lista múltiplos hosts e o psql escolhe automaticamente qual deles atender a sessão: sem esse indicador, a única forma de saber onde você está era rodar SHOW in_hot_standby manualmente a cada troca de contexto.

Controle fino de timeout em replicação

Dois parâmetros novos endereçam um problema recorrente em shutdown e em ambientes com múltiplas assinaturas lógicas:

• wal_sender_shutdown_timeout (commit a8f45dee917): limita quanto tempo o servidor espera, no desligamento, até que todo o WAL pendente seja replicado para os receptores. Por padrão não há limite, o que historicamente travava shutdowns quando o apply worker do assinante ficava preso esperando um lock.
• wal_receiver_timeout (commits 8a6af3ad087, fb80f388f4a): agora pode ser configurado por assinatura, via CREATE|ALTER SUBSCRIPTION, ou por usuário dono da assinatura, em vez de só globalmente via sighup. Útil quando um mesmo servidor mantém assinaturas para publicadores com latência de rede muito diferente entre si.

Somados, esses dois parâmetros tiram o DBA da situação de escolher entre um shutdown que nunca termina e um corte abrupto que arrisca perder WAL ainda não replicado.

GRANT/REVOKE com GRANTED BY: delegação de verdade

O padrão SQL sempre previu a cláusula GRANTED BY em GRANT/REVOKE, para especificar em nome de qual role o privilégio é concedido ou revogado. O PostgreSQL aceitava a sintaxe, mas travava com ERROR: grantor must be current user sempre que alguém tentava usar outra role que não a atual. O commit dd1398f1378 corrige isso, desde que a role citada em GRANTED BY realmente tenha o direito de conceder o privilégio e que quem executa o comando herde essa role via INHERIT.

No exemplo da fonte, charlie herda alice e bob com INHERIT true, e pode então conceder SELECT em nome de qualquer uma delas:

charlie=> GRANT SELECT ON test TO dave GRANTED BY bob;
GRANT

Isso resolve um problema estrutural de governança: até aqui, delegar a concessão de privilégios em nome de outra role exigia que o próprio owner executasse o comando, ou que o Postgres escolhesse o grantor por conta própria, sem opção de escolha. Em ambientes com múltiplos times administrando schemas diferentes sob roles compartilhadas, isso é a diferença entre auditoria confiável e um log de pg_catalog que não reflete quem de fato autorizou o quê.

Senha: aviso de expiração e o fim anunciado do MD5

Duas mudanças de segurança completam o pacote DBA3/DBS. O novo password_expiration_warning_threshold (commit 1d92e0c2cc4, padrão de 7 dias) faz o servidor avisar o usuário, no momento da conexão, quando a senha está perto de expirar:

WARNING: role password will expire soon
DETAIL: The password for role "alice" will expire in 5 hours.

E desde a versão 18 o Postgres já avisava ao definir uma senha com MD5 que o suporte seria removido; agora (commit bc60ee86066) o aviso também aparece ao autenticar com uma senha MD5 existente, o que torna muito mais difícil ignorar bases legadas que ainda não migraram para SCRAM-SHA-256. Quem administra clusters antigos devia tratar isso como prazo, não como ruído: o parâmetro md5_password_warnings silencia o aviso, mas não resolve o problema de fundo.

O que mais entrou nesta leva

Além do núcleo acima, a mesma leva do CommitFest de março de 2026 inclui itens que afetam mais o lado de replicação lógica e de empacotamento do que a rotina diária de monitoramento: CREATE|ALTER PUBLICATION com EXCEPT (TABLE ...) para excluir tabelas específicas de um FOR ALL TABLES; CREATE SUBSCRIPTION aceitando SERVER (um servidor postgres_fdw) no lugar da CONNECTION crua, permitindo gerenciar credenciais via USER MAPPING sem expor a string de conexão para quem cria a assinatura; pg_createsubscriber --logdir para gravar diagnósticos em arquivo em vez de só no console; SNI do lado do servidor via ssl_sni e o novo pg_hosts.conf, útil para provedores que servem vários clusters virtuais atrás do mesmo IP; e pg_read_all_data/pg_write_all_data agora cobrindo large objects, o que fecha uma lacuna que impedia uma role não-superusuário de fazer cópia completa de um banco com LOBs.

O que fica em aberto

Nenhuma dessas mudanças resolve, por si só, o trabalho de desenhar uma estratégia de backup ou de replicação; elas removem fricção operacional específica. pg_stat_recovery ainda não substitui ferramentas externas de observabilidade↳Observabilidade11 conteúdosObservabilidade para APIs: os desafios e benefícios dessa abordagemDev (Back & Front) · jan 2025Falhas em Observabilidade afetam os Apps e a Segurança das OrganizaçõesDev (Back & Front) · nov 2023ADK Java 1.0: O Google quer que você pare de gambiarra Python no seu backendMarketing Tech · abr 2026Ver tudo em DevSecOps → com histórico e alertas, apenas consolida o estado instantâneo. E a flexibilização do GRANTED BY exige disciplina de modelagem de roles: sem uma hierarquia de INHERIT bem pensada, a nova sintaxe não resolve nada sozinha. Como de costume num CommitFest, o valor real só aparece quando o DBA ajusta scripts e playbooks de monitoramento para de fato usar o que foi liberado, e não apenas sabe que existe.

Fonte: Planet PostgreSQL