Hvordan fungerer låsning i PostgreSQL?

Question

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.