¿Cómo funcionan los bloqueos en PostgreSQL?

Question

Accepted Answer

PostgreSQL utiliza **bloqueos** para coordinar el acceso concurrente y prevenir conflictos. Gracias a **MVCC**, las lecturas generalmente no necesitan bloqueos (los lectores no bloquean a los escritores), pero las escrituras adquieren bloqueos a nivel de fila, y varios tipos de bloqueos coordinan operaciones. Entender cómo funcionan los bloqueos ayuda a evitar contención y deadlocks.

## MVCC significa que las lecturas generalmente no se bloquean

```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.
```

## Bloqueos a nivel de fila (de escrituras y bloqueos explícitos)

```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` bloquea filas para que las transacciones concurrentes no puedan modificarlas — previniendo condiciones de carrera en operaciones de lectura-modificación-escritura (p. ej. disminuir inventario de forma segura).

## Tipos de bloqueos y bloqueos de tabla

```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).
```

## Evitar problemas de bloqueo y 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 qué es importante

Entender el bloqueo en PostgreSQL es importante para construir **aplicaciones concurrentes correctas y eficientes**, por lo que es conocimiento valioso de nivel senior para sistemas con acceso concurrente significativo a bases de datos.

La idea fundamental es que **MVCC significa que las lecturas generalmente no se bloquean** (los lectores no bloquean a los escritores — una ventaja clave de concurrencia en Postgres), por lo que el bloqueo se refiere principalmente a **escrituras y bloqueos explícitos**.

Entender **bloqueos a nivel de fila** (adquiridos por UPDATE/DELETE) y especialmente **`SELECT ... FOR UPDATE`** (bloqueando explícitamente filas para prevenir condiciones de carrera en operaciones de lectura-modificación-escritura — como disminuir inventario de forma segura o procesar un saldo, donde sin bloqueo las transacciones concurrentes podrían causar resultados incorrectos) es importante para la **corrección** en escenarios concurrentes.

Saber que **los cambios DDL/esquema pueden tomar bloqueos de tabla más pesados** (potencialmente bloqueando consultas en tablas ocupadas — una consideración importante al planificar migraciones, aunque Postgres ha mejorado muchos ALTERs para no ser bloqueantes) ayuda a evitar contención durante despliegues.

Entender cómo **evitar problemas de bloqueo y deadlocks** — mantener transacciones cortas (manteniendo bloqueos brevemente), adquirir bloqueos en orden consistente (previniendo deadlocks), usar `FOR UPDATE` deliberadamente (y `SKIP LOCKED` para patrones de cola), y diagnosticar contención de bloqueos (pg_locks, pg_stat_activity) — es valioso para el rendimiento y la confiabilidad bajo concurrencia.

Ya que la concurrencia es inherente en aplicaciones reales, y ya que el uso apropiado de bloqueos (especialmente `FOR UPDATE` para corrección en operaciones de lectura-modificación-escritura, y evitar contención/deadlocks) es lo que hace que el código concurrente de bases de datos sea correcto y eficiente, entender el bloqueo en PostgreSQL — el modelo MVCC-sin-bloqueos-de-lectura, bloqueo explícito de filas para corrección, bloqueos de tabla desde DDL, y evitar deadlocks/contención — es conocimiento valioso de nivel senior para construir aplicaciones concurrentes robustas y operar Postgres bajo carga, una preocupación frecuentemente relevante que demuestra comprensión del control concurrente de bases de datos.