Hvordan fungerer låsning i PostgreSQL?

Question

IT Interview Practice · Accepted Answer

PostgreSQL bruger **låse** til at koordinere samtidige adgange og forebygge konflikter. Takket være **MVCC** behøver læsninger generelt ikke låse (læsere blokerer ikke skrivere), men skrivninger erhverver låse på rækkeniveau, og forskellige låsetyper koordinerer operationer. At forstå låsning hjælper med at undgå konkurrence og deadlocks.

## MVCC betyder, at læsninger normalt ikke låser

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

## Låse på rækkeniveau (fra skrivninger og eksplicit låsning)

```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` låser rækker, så samtidige transaktioner ikke kan ændre dem — hvilket forhindrer race conditions i læse-modificer-skrive-operationer (f.eks. sikker nedtælling af lager).

## Låsetyper og tabellåse

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

## Undgå låseproblemer og 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)
```

## Hvorfor det betyder noget

At forstå PostgreSQL-låsning er vigtigt for at bygge **korrekte, performante samtidige applikationer**, hvilket gør det til værdifuld viden på seniorniveau for systemer med betydelig samtidig databaseadgang.

Den grundlæggende indsigt er, at **MVCC betyder, at læsninger normalt ikke låser** (læsere blokerer ikke skrivere — en vigtig fordel for samtidighed i Postgres), så låsning primært handler om **skrivninger og eksplicit låsning**.

At forstå **låse på rækkeniveau** (erhvervet af UPDATE/DELETE) og især **`SELECT ... FOR UPDATE`** (eksplicit låsning af rækker for at forebygge race conditions i læse-modificer-skrive-operationer — såsom sikker nedtælling af lager eller behandling af en saldo, hvor samtidige transaktioner uden låsning kunne forårsage forkerte resultater) er vigtig for **korrekthed** i samtidige scenarier.

Viden om, at **DDL/skemaændringer kan tage tyngre tabellåse** (som potentielt kan blokere forespørgsler på travle tabeller — en vigtig overvejelse ved planlægning af migrationer, selvom Postgres har forbedret mange ALTER-operationer til at være ikke-blokerende) hjælper med at undgå konkurrence under installationer.

At forstå, hvordan man **undgår låseproblemer og deadlocks** — holder transaktioner korte (holder låse kort), erhverver låse i konsistent rækkefølge (forebygger deadlocks), bruger `FOR UPDATE` bevidst (og `SKIP LOCKED` til køemønstre), og diagnosticerer låsekonkurrence (pg_locks, pg_stat_activity) — er værdifuldt for ydelse og pålidelighed under samtidighed.

Da samtidighed er iboende i virkelige applikationer, og da korrekt brug af låsning (især `FOR UPDATE` for korrekthed i læse-modificer-skrive-operationer, og undgåelse af konkurrence/deadlocks) er det, der gør samtididig databasekode korrekt og performant, er forståelse af PostgreSQL-låsning — MVCC-ingen-læse-låse-modellen, eksplicit rækkelåsning for korrekthed, tabellåse fra DDL, og undgåelse af deadlocks/konkurrence — værdifuld viden på seniorniveau for at bygge robuste samtidige applikationer og betjene Postgres under belastning, hvilket er en hyppigt relevant bekymring, der demonstrerer forståelse af databasekontrollering af samtidighed.

MVCC betyder, at læsninger normalt ikke låser

Låse på rækkeniveau (fra skrivninger og eksplicit låsning)

Låsetyper og tabellåse

Undgå låseproblemer og deadlocks

Hvorfor det betyder noget

Relaterede spørgsmål