Comment fonctionne le verrouillage dans PostgreSQL ?

Question

Accepted Answer

PostgreSQL utilise des **verrous** pour coordonner l'accès concurrent et prévenir les conflits. Grâce à **MVCC**, les lectures ne nécessitent généralement pas de verrous (les lecteurs ne bloquent pas les écrivains), mais les écritures acquièrent des verrous au niveau des lignes, et différents types de verrous coordonnent les opérations. Comprendre le verrouillage aide à éviter la contention et les deadlocks.

## MVCC signifie que les lectures ne verrouillent généralement pas

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

## Verrous au niveau des lignes (à partir des écritures et du verrouillage explicite)

```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` verrouille les lignes afin que les transactions concurrentes ne puissent pas les modifier — prévenant les conditions de course dans les opérations de lecture-modification-écriture (p. ex. diminuer de manière sécurisée l'inventaire).

## Types de verrous et verrous de table

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

## Éviter les problèmes de verrouillage et les 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)
```

## Pourquoi c'est important

Comprendre le verrouillage PostgreSQL est important pour construire des **applications concurrentes correctes et performantes**, c'est donc une connaissance précieuse de niveau senior pour les systèmes avec un accès concurrent significatif à la base de données.

L'insight fondamental est que **MVCC signifie que les lectures ne verrouillent généralement pas** (les lecteurs ne bloquent pas les écrivains — un avantage clé de la concurrence Postgres), donc le verrouillage concerne principalement les **écritures et le verrouillage explicite**.

Comprendre les **verrous au niveau des lignes** (acquis par UPDATE/DELETE) et en particulier **`SELECT ... FOR UPDATE`** (verrouiller explicitement les lignes pour prévenir les conditions de course dans les opérations de lecture-modification-écriture — comme diminuer de manière sécurisée l'inventaire ou traiter un solde, où sans verrouillage les transactions concurrentes pourraient produire des résultats incorrects) est important pour la **correction** dans les scénarios concurrents.

Savoir que les **changements DDL/schéma peuvent prendre des verrous de table plus lourds** (bloquant potentiellement les requêtes sur les tables occupées — une considération importante lors de la planification des migrations, bien que Postgres ait amélioré de nombreuses ALTERs pour être non-bloquantes) aide à éviter la contention pendant les déploiements.

Comprendre comment **éviter les problèmes de verrouillage et les deadlocks** — garder les transactions courtes (tenir les verrous brièvement), acquérir les verrous dans un ordre cohérent (prévenir les deadlocks), utiliser `FOR UPDATE` délibérément (et `SKIP LOCKED` pour les motifs de file d'attente), et diagnostiquer la contention de verrous (pg_locks, pg_stat_activity) — est précieux pour la performance et la fiabilité sous concurrence.

Puisque la concurrence est inhérente aux applications réelles, et puisque l'utilisation appropriée du verrouillage (en particulier `FOR UPDATE` pour la correction dans les opérations de lecture-modification-écriture, et éviter la contention/les deadlocks) est ce qui rend le code de base de données concurrent correct et performant, comprendre le verrouillage PostgreSQL — le modèle MVCC-sans-verrous-de-lecture, le verrouillage explicite des lignes pour la correction, les verrous de table du DDL, et l'évitement des deadlocks/contention — est une connaissance précieuse de niveau senior pour construire des applications concurrentes robustes et exploiter Postgres sous charge, une préoccupation fréquemment pertinente qui démontre une compréhension du contrôle de concurrence de base de données.