Jak funguje zamykání v PostgreSQL?

Question

Accepted Answer

PostgreSQL používá **zámky** pro koordinaci souběžného přístupu a prevenci konfliktů. Díky **MVCC** obvykle nepotřebují zámky čtení (čtenáři neblokují zapisovatele), ale zápisy získávají zámky na úrovni řádků a různé typy zámků koordinují operace. Pochopení zamykání pomáhá vyhnout se soutěži a deadlocků.

## MVCC znamená, že čtení obvykle neuzamyká

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

## Zámky na úrovni řádků (ze zápisů a explicitního zamykání)

```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` zamyká řádky, aby je souběžné transakce nemohly upravovat — zabraňuje race conditions v operacích read-modify-write (např. bezpečné snížení inventáře).

## Typy zámků a zámky tabulek

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

## Vyhýbání se problémům se zámky a deadlock-ům

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

## Proč na tom záleží

Pochopení zamykání v PostgreSQL je důležité pro vytváření **správných a výkonných souběžných aplikací**, takže jde o cenné znalosti pro seniorní úroveň pro systémy s významným souběžným přístupem do databáze.

Základním poznatkem je, že **MVCC znamená, že čtení obvykle neuzamyká** (čtenáři neblokují zapisovatele — klíchová výhoda souběžnosti Postgresu), takže zamykání se týká především **zápisů a explicitního zamykání**.

Pochopení **zámků na úrovni řádků** (získávaných UPDATE/DELETE) a zejména **`SELECT ... FOR UPDATE`** (explicitního zamykání řádků pro prevenci race conditions v operacích read-modify-write — jako bezpečné snížení inventáře nebo zpracování zůstatku, kde bez zamykání by souběžné transakce mohly způsobit nesprávné výsledky) je důležité pro **správnost** v souběžných scénářích.

Vědomí, že **DDL/změny schématu mohou nabíhat těžší zámky tabulek** (potenciálně blokující dotazy na rušných tabulkách — důležité hledisko při plánování migrací, ačkoli PostgreSQL vylepšil mnoho ALTERů tak, aby byly non-blocking) pomáhá vyhnout se soutěži během nasazení.

Pochopení, jak **vyhýbat se problémům se zámky a deadlock-ům** — udržování transakcí krátkých (uchování zámků krátce), získávání zámků v konzistentním pořadí (prevence deadlock-ů), používání `FOR UPDATE` deliberátně (a `SKIP LOCKED` pro queue patterns) a diagnostika lock contention (`pg_locks`, `pg_stat_activity`) — je cenné pro výkon a spolehlivost pod souběžností.

Protože je souběžnost vlastní skutečným aplikacím a protože správné použití zamykání (zejména `FOR UPDATE` pro správnost v operacích read-modify-write a vyhýbání se soutěži/deadlock-ům) je to, co činí souběžný databázový kód správným a výkonným, pochopení zamykání v PostgreSQL — model MVCC bez read-lock-ů, explicitní row locking pro správnost, table locks z DDL a vyhýbání se deadlock-ům/soutěži — je cenné znalosti na seniorní úrovni pro vytváření robustních souběžných aplikací a provoz Postgresu pod zatížením, což je často relevantní záležitost, která demonstruje pochopení řízení souběžnosti databází.