Pular para o conteúdo

Wait Event Types

Wait event type é a categoria do motivo pelo qual um processo do PostgreSQL está parado. O tipo aparece em pg_stat_activity.wait_event_type; o evento específico fica em wait_event. Agrupar as esperas por tipo ajuda a separar ociosidade, espera de cliente, I/O, locks e contenção interna.

Quando um processo não pode seguir na hora (ler um bloco, gravar WAL, pegar um lock ou receber o próximo comando), ele registra a espera. As colunas wait_event e state são independentes: uma sessão active pode estar executando uma query e, ao mesmo tempo, bloqueada em algum evento.

1. Activity O processo está ocioso no próprio loop principal, sem trabalho pendente. Não é contenção: está esperando a próxima tarefa. Exemplo: o checkpointer em CheckpointerMain ou o autovacuum launcher em AutovacuumMain entre um ciclo e outro.

2. BufferPin O processo quer um pin exclusivo em um buffer de dados, mas outro processo ainda o segura. A espera pode se alongar se um cursor aberto tiver lido aquele buffer por último. Exemplo: um VACUUM ou um UPDATE fica em BufferPin porque uma sessão mantém um cursor aberto sobre a mesma página.

3. Client O servidor espera algo no socket da aplicação, fora do controle interno do banco. Exemplo: um backend em ClientRead depois de devolver o resultado, enquanto a aplicação demora para enviar o próximo comando; ou um commit síncrono em WaitForStandbyConfirmation, aguardando o standby confirmar o WAL.

4. Extension A espera foi definida por uma extensão, não pelo núcleo. O único evento pré-definido é Extension. Exemplo: um worker de pg_cron ou de uma fila parado até a extensão liberar a condição que ela mesma registrou.

5. InjectionPoint O processo espera um injection point chegar ao resultado definido em um teste. Não há wait points pré-definidos; é um mecanismo de teste do servidor. Exemplo: um teste de regressão do PostgreSQL injeta uma pausa para forçar uma corrida entre dois backends.

6. IO O processo espera uma operação de entrada e saída terminar: leitura, escrita, extend ou fsync de arquivos de dados, WAL e de controle. Exemplo: um SELECT grande em DataFileRead porque os blocos não estão no shared buffer; ou um commit em WalSync enquanto o WAL é gravado em disco.

7. IPC O processo espera outro processo do mesmo servidor: paralelismo, replicação, checkpoint ou comandos de archive e restore. Exemplo: o líder de uma query paralela em ExecuteGather enquanto os workers ainda não devolvem linhas; ou um commit com synchronous_commit em SyncRep, esperando a confirmação do standby.

8. Lock Espera por um heavyweight lock, o lock do lock manager. Protege objetos visíveis no SQL (tabelas, linhas, transações) e também algumas operações internas, como estender uma relação. Exemplo: um UPDATE na mesma linha fica em tuple ou transactionid até o UPDATE anterior fazer commit; um ALTER TABLE fica em relation atrás de um SELECT longo.

9. LWLock Espera por um lightweight lock, em geral sobre uma estrutura na memória compartilhada. São esperas curtas; quando se acumulam, indicam contenção interna. Exemplo: muitas sessões em WALInsert num pico de escrita, disputando a inserção no buffer de WAL; ou em BufferContent ao acessar a mesma página quente.

10. Timeout O processo espera um prazo configurado expirar, de propósito. Exemplo: um VACUUM em VacuumDelay por causa de vacuum_cost_delay; um standby em RecoveryApplyDelay por recovery_min_apply_delay; ou uma sessão em PgSleep depois de SELECT pg_sleep(10).

pg_stat_activity: uma linha por processo, com wait_event_type, wait_event e state.

SELECT pid, wait_event_type, wait_event
FROM pg_stat_activity
WHERE wait_event IS NOT NULL;