O pg_statviz 1.2 chega com suporte ao PostgreSQL 19 e análise de bloqueios

Foi lançada a versão 1.2 do pg_statviz, a dupla extensão-mais-utilitário voltada para análise de séries temporais e visualização das estatísticas internas do 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 →. O lançamento chega em cima das primeiras betas do PostgreSQL 19 e vale a atenção de quem administra bancos em produção sem querer instalar plataformas de monitoramento pesadas.

O que é o pg_statviz, para quem não conhece

A proposta da ferramenta é deliberadamente enxuta. Em vez de depender de agentes invasivos ou de conexões abertas permanentemente contra o banco, como fazem várias plataformas comerciais, o pg_statviz vive dentro do próprio banco. A extensão é escrita em SQL puro e PL/pgSQL, não exige módulos carregados na inicialização, e coleta snapshots periódicos das estatísticas internas (as views pg_stat_*).

A parte de visualização é separada: um utilitário Python↳Python56 conteúdosVSCode + Python + Alexa: Desenvolva e teste skills para alexa localmente com pythonDev (Back & Front) · out 2025Dominando decoradores em Python: um guia completo com exemplosDev (Back & Front) · jan 2025Desenvolvimento de software: diferenças entre Python, JavaScript e JavaGestão Dev & TI · nov 2024Ver tudo em Dev (Back & Front) → que pode rodar de qualquer lugar, lê os snapshots armazenados e gera os gráficos. Os dados coletados são seus, ficam no seu banco e são fáceis de exportar. Para o DBA que trabalha em ambientes com restrição de rede ou compliance, esse desenho importa: nada sai da máquina a menos que você mande.

Suporte ao PostgreSQL 19

O principal motivo da release é acompanhar a chegada da v19. Três pontos concretos:

• O pg_statviz passa a capturar o novo contador wal_fpi_bytes da view pg_stat_wal, útil para acompanhar o volume de full page images geradas no WAL, um dado relevante para quem investiga picos de escrita.
• Configurações introduzidas nas versões 18 e 19, como o I/O worker, o effective WAL level e os parâmetros de scoring do autovacuum, passam a ser registradas em snapshot_conf.
• A versão foi testada contra a 19 beta3 e em toda a faixa do PostgreSQL 13 ao 19, o que dá margem para adotar sem trocar de major.

O novo módulo de locks bloqueantes

Esta é a adição mais interessante do ponto de vista de diagnóstico em produção. Cada snapshot agora registra o número de sessões bloqueadas e bloqueadoras, com detalhamento por tipo de lock (relation, transactionid, tuple e assim por diante).

A detecção é construída sobre pg_blocking_pids(), e aqui está um detalhe que faz diferença na prática: são contados também os soft blocks, ou seja, sessões que estão apenas à frente na fila de espera pelo lock, não só os conflitos duros. Quem já perseguiu contenção intermitente sabe o quanto esse tipo de espera passa despercebido em coletas mais grosseiras.

O custo de armazenamento se mantém leve: o tamanho da tabela é independente da quantidade de sessões envolvidas no bloqueio, o que evita que um pico de contenção estufe o histórico de coleta. O módulo produz gráficos como os demais e também emite verdicts de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI →, mas com uma salvaguarda determinística que merece nota: existe um piso de severidade que impede que bloqueio sustentado seja reportado como saudável. Ou seja, mesmo que o modelo de linguagem se anime, contenção prolongada não vira "tudo bem".

IA opcional, agora com provedor OpenAI

A análise por IA continua totalmente opcional e opt-in. Se você não passar a flag --ai, o comportamento é exatamente o de antes: sem dependências extras e sem nenhuma chamada para fora da sua máquina. Isso é coerente com a filosofia minimalista e tranquiliza quem não quer dados trafegando para serviços externos.

Para quem quiser usar, a novidade é o provedor openai:

• --ai openai usa a API da OpenAI, e como o formato virou padrão de fato, o mesmo flag funciona com a própria OpenAI ou com qualquer outro serviço, ou servidor local, que implemente essa API.
• O endpoint e o modelo são escolhidos pelas variáveis de ambiente OPENAI_BASE_URL e OPENAI_MODEL, o que abre caminho para apontar para um modelo rodando localmente.
• O pacote openai entrou nos extras [ai]; instalações sem dependências continuam iguais.

Os modelos padrão também foram atualizados para claude-sonnet-5 no Claude e gemini-3.7-flash no Gemini.

Como instalar

A extensão pode ser baixada e instalada a partir dos repositórios oficiais do PostgreSQL ou do PGXN. O utilitário de visualização está no PyPI:

pip install pg_statviz

Para habilitar os recursos de IA:

pip install pg_statviz[ai]

A instalação manual também é possível.

O que muda para o DBA brasileiro

Em ambientes onde a fatura de ferramentas de APM e monitoramento pesa, ou onde políticas de segurança dificultam agentes externos e conexões persistentes, o pg_statviz oferece um caminho de baixo atrito: coleta interna, dados sob seu controle e visualização desacoplada. O módulo de locks bloqueantes cobre uma dor recorrente em produção, contenção que aparece e some, com detecção sensível o suficiente para pegar esperas na fila, e o piso de severidade determinístico é um cuidado saudável contra confiar cegamente no veredito de um LLM.

O ponto de atenção continua sendo o de sempre com coleta por snapshots: a granularidade do seu diagnóstico depende da frequência com que você agenda as coletas. Contenções muito rápidas entre dois snapshots podem escapar. Vale desenhar o intervalo de coleta conforme o perfil de carga antes de tirar conclusões sobre picos que não apareceram no gráfico.

Fonte: Planet PostgreSQL