Como o bloqueio funciona no PostgreSQL?

Question

Accepted Answer

O PostgreSQL usa **bloqueios** para coordenar acesso concorrente e prevenir conflitos. Graças ao **MVCC**, leituras geralmente não precisam de bloqueios (leitores não bloqueiam escritores), mas escritas adquirem bloqueios em nível de linha, e vários tipos de bloqueio coordenam operações. Entender bloqueio ajuda a evitar contenção e deadlocks.

## MVCC significa que leituras geralmente não são bloqueadas

```text
Because of MVCC, plain SELECTs do NOT take row locks — they read a consistent snapshot.
→ Readers don't block writers, writers don't block readers (a key Postgres advantage).
Locking mainly comes into play for WRITES and explicit locking.
```

## Bloqueios em nível de linha (de escritas e bloqueio explícito)

```sql
-- UPDATE/DELETE automatically lock the affected ROWS (until the transaction ends)
UPDATE accounts SET balance = balance - 100 WHERE id = 1;   -- locks row 1

-- SELECT ... FOR UPDATE — explicitly lock rows you intend to update (prevent races)
BEGIN;
SELECT * FROM accounts WHERE id = 1 FOR UPDATE;   -- lock the row
-- ... compute, then UPDATE — no other transaction can modify it meanwhile
UPDATE accounts SET balance = ... WHERE id = 1;
COMMIT;
```

`SELECT ... FOR UPDATE` bloqueia linhas para que transações concorrentes não possam modificá-las — prevenindo race conditions em operações read-modify-write (por exemplo, decrementar com segurança o inventário).

## Tipos de bloqueio e bloqueios de tabela

```text
ROW-level → ACCESS via UPDATE/DELETE/SELECT FOR UPDATE — fine-grained
TABLE-level → some DDL (ALTER TABLE) takes heavier table locks → can block queries
→ Schema changes on busy tables can cause contention; plan migrations carefully
  (Postgres has gotten better — many ALTERs are now non-blocking, but not all).
```

## Evitando problemas de bloqueio e deadlocks

```text
✓ Keep transactions SHORT (hold locks briefly → less contention)
✓ Acquire locks in a CONSISTENT ORDER across transactions → avoid DEADLOCKS
✓ Use FOR UPDATE deliberately for read-modify-write; consider FOR UPDATE SKIP LOCKED
  for queue-like patterns (skip already-locked rows)
✓ Watch for long-held locks blocking others (pg_locks, pg_stat_activity to diagnose)
✓ Be cautious with DDL on busy tables (can block)
```

## Por que isso importa

Entender o bloqueio do PostgreSQL é importante para construir **aplicações concorrentes corretas e performáticas**, portanto é um conhecimento valioso de nível sênior para sistemas com acesso concorrente significativo ao banco de dados.

O insight fundamental é que **MVCC significa que leituras geralmente não são bloqueadas** (leitores não bloqueiam escritores — uma vantagem chave de concorrência do Postgres), então o bloqueio diz respeito principalmente a **escritas e bloqueio explícito**.

Entender **bloqueios em nível de linha** (adquiridos por UPDATE/DELETE) e especialmente **`SELECT ... FOR UPDATE`** (bloqueando explicitamente linhas para prevenir race conditions em operações read-modify-write — como decrementar com segurança um inventário ou processar um saldo, onde sem bloqueio transações concorrentes poderiam causar resultados incorretos) é importante para **correção** em cenários concorrentes.

Saber que **alterações DDL/schema podem exigir bloqueios de tabela mais pesados** (potencialmente bloqueando consultas em tabelas ocupadas — uma consideração importante ao planejar migrações, embora o Postgres tenha melhorado muitas ALTERs para serem não-bloqueantes) ajuda a evitar contenção durante implantações.

Entender como **evitar problemas de bloqueio e deadlocks** — manter transações curtas (segurando bloqueios brevemente), adquirir bloqueios em ordem consistente (prevenindo deadlocks), usar `FOR UPDATE` deliberadamente (e `SKIP LOCKED` para padrões de fila), e diagnosticar contenção de bloqueio (pg_locks, pg_stat_activity) — é valioso para performance e confiabilidade sob concorrência.

Como a concorrência é inerente em aplicações reais, e como o uso apropriado de bloqueio (especialmente `FOR UPDATE` para correção em operações read-modify-write, e evitar contenção/deadlocks) é o que torna o código de banco de dados concorrente correto e performático, entender o bloqueio do PostgreSQL — o modelo MVCC-sem-bloqueios-de-leitura, bloqueio explícito de linha para correção, bloqueios de tabela do DDL, e evitar deadlocks/contenção — é um conhecimento valioso de nível sênior para construir aplicações concorrentes robustas e operar Postgres sob carga, uma preocupação frequentemente relevante que demonstra entendimento de controle de concorrência em banco de dados.