Hoe werkt vergrendeling in PostgreSQL?

Question

Accepted Answer

PostgreSQL gebruikt **locks** om gelijktijdige toegang te coördineren en conflicten te voorkomen. Dankzij **MVCC** hebben leesbewerkingen over het algemeen geen locks nodig (lezers blokkeren schrijvers niet), maar schrijfbewerkingen verwerven locks op rijniveau, en verschillende soorten locks coördineren bewerkingen. Het begrijpen van vergrendeling helpt contention en deadlocks te vermijden.

## MVCC betekent dat leesbewerkingen meestal niet vergrendeld zijn

```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 op rijniveau (van schrijfbewerkingen en expliciete vergrendeling)

```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` vergrendelt rijen zodat gelijktijdige transacties deze niet kunnen wijzigen — dit voorkomt race conditions in read-modify-write-bewerkingen (bijvoorbeeld het veilig verminderen van voorraad).

## Lock-typen en tabelvergrendelingen

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

## Lock-problemen en deadlocks voorkomen

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

## Waarom het belangrijk is

Het begrijpen van PostgreSQL-vergrendeling is belangrijk voor het bouwen van **correcte, performante gelijktijdige toepassingen**, dus het is waardevolle kennis op senior-niveau voor systemen met aanzienlijke gelijktijdige databasetoegang.

De fundamentele inzicht is dat **MVCC betekent dat leesbewerkingen meestal niet vergrendeld zijn** (lezers blokkeren schrijvers niet — een belangrijk voordeel van PostgreSQL-gelijktijdigheid), dus vergrendeling betreft primair **schrijfbewerkingen en expliciete vergrendeling**.

Het begrijpen van **locks op rijniveau** (verworven door UPDATE/DELETE) en vooral **`SELECT ... FOR UPDATE`** (expliciete vergrendeling van rijen om race conditions in read-modify-write-bewerkingen te voorkomen — zoals het veilig verminderen van voorraad of verwerken van een saldo, waarbij gelijktijdige transacties zonder vergrendeling tot onjuiste resultaten kunnen leiden) is belangrijk voor **correctheid** in gelijktijdige scenario's.

Weten dat **DDL/schema-wijzigingen kunnen zwaardere tabelvergrendelingen krijgen** (mogelijk queries blokkeren op drukke tabellen — een belangrijk aandachtspunt bij het plannen van migraties, hoewel PostgreSQL veel ALTER-bewerkingen non-blocking heeft gemaakt) helpt contention tijdens deployments te voorkomen.

Het begrijpen hoe je **lock-problemen en deadlocks vermijdt** — transacties kort houden (locks kort vasthouden), locks in consistente volgorde verwerven (deadlocks voorkomen), `FOR UPDATE` doelbewust gebruiken (en `SKIP LOCKED` voor wachtrij-patronen), en lock contention diagnosticeren (pg_locks, pg_stat_activity) — is waardevol voor prestaties en betrouwbaarheid onder gelijktijdigheid.

Omdat gelijktijdigheid inherent is aan echte toepassingen, en omdat correct gebruik van vergrendeling (vooral `FOR UPDATE` voor correctheid in read-modify-write-bewerkingen, en het vermijden van contention/deadlocks) is wat gelijktijdige databasecode correct en performant maakt, is het begrijpen van PostgreSQL-vergrendeling — het MVCC-geen-read-locks-model, expliciete rijvergrendeling voor correctheid, tabelvergrendelingen van DDL, en het vermijden van deadlocks/contention — waardevolle kennis op senior-niveau voor het bouwen van robuuste gelijktijdige toepassingen en het bedrijven van Postgres onder belasting, een regelmatig relevant aandachtspunt dat begrijpen van databasegelijktijdigheidsbeheer aantoont.