Hur fungerar låsning i PostgreSQL?

Question

Accepted Answer

PostgreSQL använder **locks** för att koordinera samtidig åtkomst och förhindra konflikter. Tack vare **MVCC** behöver läsningar vanligtvis inte låsningar (läsare blockerar inte skrivare), men skrivningar förvärvar radnivålåsningar, och olika låsningstyper koordinerar operationer. Att förstå låsning hjälper till att undvika konkurrens och dödlägen.

## MVCC innebär att läsningar vanligtvis inte 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.
```

## Radnivålåsningar (från skrivningar och explicit 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 rader så att samtidiga transaktioner inte kan ändra dem — vilket förhindrar race conditions i läs-ändra-skriv-operationer (t.ex. säker minskning av lager).

## Låsningstyper och tabellåsningar

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

## Undvika låsproblem och dödlägen

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

## Varför det är viktigt

Att förstå PostgreSQL-låsning är viktigt för att bygga **korrekta, högpresterande samtidiga applikationer**, så det är värdefullt kunskap på seniornivå för system med betydande samtidig databasåtkomst.

Den grundläggande insikten är att **MVCC innebär att läsningar vanligtvis inte låser** (läsare blockerar inte skrivare — en nyckel Postgres-fördel vid samtidighet), så låsning handlar främst om **skrivningar och explicit låsning**.

Att förstå **radnivålåsningar** (förvärvade av UPDATE/DELETE) och speciellt **`SELECT ... FOR UPDATE`** (explicit låsning av rader för att förhindra race conditions i läs-ändra-skriv-operationer — som säker minskning av lager eller bearbetning av saldo, där utan låsning kunde samtidiga transaktioner orsaka felaktiga resultat) är viktigt för **korrekthet** i samtidiga scenarier.

Att veta att **DDL/schemaändringar kan ta tyngre tabellåsningar** (potentiellt blockera frågor på upptagna tabeller — en viktig hänsyn vid planering av migrationer, även om Postgres har förbättrat många ALTER för att vara icke-blockerande) hjälper till att undvika konkurrens under distributioner.

Att förstå hur man **undviker låsproblem och dödlägen** — hålla transaktioner korta (hålla låsningar kort), förvärva låsningar i konsekvent ordning (förhindra dödlägen), använda `FOR UPDATE` avsiktligt (och `SKIP LOCKED` för köer), och diagnostisera låskonkurrens (pg_locks, pg_stat_activity) — är värdefullt för prestanda och tillförlitlighet under samtidighet.

Eftersom samtidighet är inneboende i verkliga applikationer, och eftersom korrekt användning av låsning (speciellt `FOR UPDATE` för korrekthet i läs-ändra-skriv-operationer, och undvikande av konkurrens/dödlägen) är det som gör samtidig databaskod korrekt och högpresterande, är förståelse för PostgreSQL-låsning — MVCC-ingen-läs-låsningar-modellen, explicit radlåsning för korrekthet, tabellåsningar från DDL, och undvikande av dödlägen/konkurrens — värdefullt kunskap på seniornivå för att bygga robusta samtidiga applikationer och driva Postgres under belastning, en ofta relevant fråga som visar förståelse för databaskontroll vid samtidighet.