Hvordan fungerer låsing i PostgreSQL?

Question

Accepted Answer

PostgreSQL bruker **låser** for å koordinere samtid tilgang og forhindre konflikter. Takket være **MVCC**, trenger lesinger generelt ikke låser (lesere blokkerer ikke skrivere), men skrivinger skaffer seg rad-nivå låser, og ulike låsetyper koordinerer operasjoner. Forståelse av låsing hjelper til med å unngå konkurranse og dødlåser.

## MVCC betyr at lesinger vanligvis 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.
```

## Rad-nivå låser (fra skrivinger og eksplisitt låsing)

```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 rader slik at samtid transaksjoner ikke kan endre dem — forhindrer løpetilstander i lese-modifiser-skriv-operasjoner (f.eks. trygt redusering av inventar).

## Låsetyper og tabel-låser

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

## Unngå låseproblemer og dødlåser

```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 er viktig

Forståelse av PostgreSQL-låsing er viktig for å bygge **korrekte, ytelseseffektive samtid applikasjoner**, så det er verdifull senior-nivå kunnskap for systemer med betydelig samtid databasetilgang.

Den grunnleggende innsikten er at **MVCC betyr at lesinger vanligvis ikke låser** (lesere blokkerer ikke skrivere — en nøkkelvantage for Postgres samtidighet), så låsing gjelder primært **skrivinger og eksplisitt låsing**.

Forståelse av **rad-nivå låser** (anskaffet av UPDATE/DELETE) og spesielt **`SELECT ... FOR UPDATE`** (eksplisitt låsing av rader for å forhindre løpetilstander i lese-modifiser-skriv-operasjoner — som trygt redusering av inventar eller behandling av en saldo, der uten låsing samtid transaksjoner kunne forårsake feil resultater) er viktig for **korrekthet** i samtid scenarier.

Viten om at **DDL/skjema-endringer kan ta tyngre tabel-låser** (potensielt blokkering av spørringer på travle tabeller — en viktig vurdering når planlegging av migrasjoner, selv om Postgres har forbedret mange ALTERs til å være ikke-blokkering) hjelper til med å unngå konkurranse under utplasseringer.

Forståelse av hvordan du **unngår låseproblemer og dødlåser** — holde transaksjoner korte (holde låser kort), skaffe låser i konsistent rekkefølge (forhindring av dødlåser), bruk `FOR UPDATE` bevisst (og `SKIP LOCKED` for kø-mønstre), og diagnostisering av låse-konkurranse (pg_locks, pg_stat_activity) — er verdifull for ytelse og pålitelighet under samtidighet.

Siden samtidighet er iboende i virkelige applikasjoner, og siden riktig bruk av låsing (spesielt `FOR UPDATE` for korrekthet i lese-modifiser-skriv-operasjoner, og unngå konkurranse/dødlåser) er det som gjør samtid databasekode korrekt og ytelseseffektiv, forståelse av PostgreSQL-låsing — MVCC-ingen-lese-låser-modellen, eksplisitt rad-låsing for korrekthet, tabel-låser fra DDL, og unngå dødlåser/konkurranse — er verdifull senior-nivå kunnskap for å bygge robuste samtid applikasjoner og drive Postgres under belastning, et hyppig relevant problem som demonstrerer forståelse av databasesamtidighet kontroll.