Cum funcționează blocarea în PostgreSQL?

Question

Accepted Answer

PostgreSQL utilizează **locks** pentru a coordona accesul concurent și a preveni conflictele. Datorită **MVCC**, citirile în general nu au nevoie de locks (cititorii nu blochează scriitorii), dar scrierile achiziționează locks la nivel de rând, iar diferite tipuri de lock coordonează operațiile. Înțelegerea blocării ajută la evitarea conținutului și a deadlock-urilor.

## MVCC înseamnă că citirile de obicei nu blochează

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

## Locks la nivel de rând (din scrieri și blocare explicită)

```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` blochează rândurile, astfel încât tranzacțiile concurente nu le pot modifica — prevenind condiții de curs în operații citire-modifica-scrie (de exemplu, scăderea sigură a inventarului).

## Tipuri de lock și locks la nivel de tabel

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

## Evitarea problemelor de blocare și deadlock-urilor

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

## De ce contează

Înțelegerea blocării în PostgreSQL este importantă pentru construirea de **aplicații concurente corecte și performante**, deci este cunoaștere valoroasă de nivel senior pentru sisteme cu acces concurent semnificativ la baza de date.

Insight-ul fundamental este că **MVCC înseamnă că citirile de obicei nu blochează** (cititorii nu blochează scriitorii — un avantaj cheie al concurenței în Postgres), deci blocarea se referă în principal la **scrieri și blocare explicită**.

Înțelegerea **locks-urilor la nivel de rând** (achiziționați de UPDATE/DELETE) și mai ales **`SELECT ... FOR UPDATE`** (blocarea explicită a rândurilor pentru a preveni condițiile de curs în operații citire-modifica-scrie — ca scăderea sigură a inventarului sau procesarea unui sold, unde fără blocare tranzacțiile concurente ar putea provoca rezultate incorecte) este importantă pentru **corectitudine** în scenariile concurente.

Știind că **schimbările DDL/schema pot lua locks de tabel mai grele** (blocând potențial interogări pe tabele ocupate — o considerație importantă la planificarea migrațiilor, deși Postgres a îmbunătățit multe ALTER-uri să fie non-blocking) ajută la evitarea conținutului în timpul implementărilor.

Înțelegerea cum să **eviți problemele de blocare și deadlock-urile** — păstrând tranzacțiile scurte (ținând locks scurt), achiziționând locks în ordine consecventă (prevenind deadlock-urile), folosind `FOR UPDATE` deliberat (și `SKIP LOCKED` pentru modele de coadă), și diagnosticarea conținutului de blocare (pg_locks, pg_stat_activity) — este valoroasă pentru performanță și fiabilitate sub concurență.

Cum concurența este inerentă în aplicațiile reale, și cum utilizarea corectă a blocării (mai ales `FOR UPDATE` pentru corectitudine în operații citire-modifica-scrie, și evitarea conținutului/deadlock-urilor) este ceea ce face codul concurent de bază de date corect și performant, înțelegerea blocării PostgreSQL — modelul MVCC-no-read-locks, blocarea explicită la nivel de rând pentru corectitudine, locks de tabel din DDL, și evitarea deadlock-urilor/conținutului — este cunoaștere valoroasă de nivel senior pentru construirea aplicațiilor concurente robuste și operarea Postgres sub sarcină, o preocupare frecvent relevantă care demonstrează înțelegere a controlului concurenței la baza de date.