Come funziona il locking in PostgreSQL?

Question

Accepted Answer

PostgreSQL utilizza **lock** per coordinare l'accesso concorrente e prevenire conflitti. Grazie a **MVCC**, le letture generalmente non richiedono lock (i lettori non bloccano gli scrittori), ma le scritture acquisiscono lock a livello di riga, e vari tipi di lock coordinano le operazioni. Comprendere il locking aiuta a evitare contention e deadlock.

## MVCC significa che le letture di solito non bloccano

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

## Lock a livello di riga (da scritture e locking esplicito)

```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` blocca le righe in modo che le transazioni concorrenti non possono modificarle — prevenendo race condition nelle operazioni read-modify-write (ad es. decrementare in modo sicuro l'inventario).

## Tipi di lock e lock di tabella

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

## Evitare problemi di lock e deadlock

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

## Perché è importante

Comprendere il locking di PostgreSQL è importante per costruire **applicazioni concorrenti corrette e performanti**, quindi è una conoscenza preziosa a livello senior per sistemi con accesso concorrente significativo al database.

L'intuizione fondamentale è che **MVCC significa che le letture di solito non bloccano** (i lettori non bloccano gli scrittori — un vantaggio chiave di concorrenza di Postgres), quindi il locking riguarda principalmente **le scritture e il locking esplicito**.

Comprendere i **lock a livello di riga** (acquisiti da UPDATE/DELETE) e soprattutto **`SELECT ... FOR UPDATE`** (bloccando esplicitamente le righe per prevenire race condition nelle operazioni read-modify-write — come decrementare in modo sicuro l'inventario o elaborare un saldo, dove senza locking le transazioni concorrenti potrebbero causare risultati scorretti) è importante per la **correttezza** in scenari concorrenti.

Sapere che i **cambiamenti DDL/schema possono acquisire lock di tabella più pesanti** (potenzialmente bloccando le query su tabelle occupate — una considerazione importante quando si pianificano migrazioni, anche se Postgres ha migliorato molti ALTER per essere non-bloccanti) aiuta a evitare contention durante i deployment.

Comprendere come **evitare problemi di lock e deadlock** — mantenere le transazioni brevi (tenendo i lock brevemente), acquisire i lock in ordine coerente (prevenendo deadlock), utilizzare `FOR UPDATE` deliberatamente (e `SKIP LOCKED` per pattern di coda), e diagnosticare contention di lock (pg_locks, pg_stat_activity) — è prezioso per le prestazioni e l'affidabilità sotto concorrenza.

Poiché la concorrenza è intrinseca nelle applicazioni reali, e poiché l'uso appropriato del locking (soprattutto `FOR UPDATE` per la correttezza nelle operazioni read-modify-write, e l'evitamento di contention/deadlock) è ciò che rende il codice del database concorrente corretto e performante, comprendere il locking di PostgreSQL — il modello MVCC-no-read-locks, il locking esplicito di righe per la correttezza, i lock di tabella da DDL, e l'evitamento di deadlock/contention — è una conoscenza preziosa a livello senior per costruire applicazioni concorrenti robuste e operare Postgres sotto carico, una preoccupazione frequentemente rilevante che dimostra la comprensione del controllo di concorrenza del database.