როგორ მუშაობს ბლოკირება PostgreSQL-ში?

Question

Accepted Answer

PostgreSQL იყენებს **locks-ებს** ერთდროული წვდომის კოორდინაციისთვის და კონფლიქტების თავიდან აცილებისთვის. **MVCC**-ს წყალობით, კითხვები ზოგადად არ საჭიროებენ locks-ებს (მკითხველები არ ბლოკავენ writers-ებს), მაგრამ ჩაწერებები იძენენ row-level locks-ებს, და სხვადსხვა lock types-ები კოორდინაციას უკეთებენ ოპერაციებს. ბლოკირების გაგება ეხმარება contention-ის და deadlock-ების თავიდან აცილებაში.

## MVCC ნიშნავს რომ კითხვები ჩვეულებრივ არ ბლოკირდებიან

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

## Row-level locks (ჩაწერებებიდან და ექსპლიციტური ბლოკირებიდან)

```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` ბლოკირებს ხაზებს, ასე რომ ერთდროული ტრანზაქციები ვერ შეცვლიან მათ — race conditions-ის თავიდან აცილება read-modify-write ოპერაციებში (მაგ. უსაფრთხოდ inventory-ის შემცირება).

## Lock types-ები და table locks-ები

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

## Lock პრობლემებისა და deadlock-ების თავიდან აცილება

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

## რატომ არის მნიშვნელოვანი

PostgreSQL ბლოკირების გაგება მნიშვნელოვანია **სწორი, მაღალი ფუნქციონირების ერთდროული აპლიკაციების** აგებისთვის, ამიტომ ეს ღირებული senior-level ცოდნაა სისტემებისთვის, რომელსაც მნიშვნელოვანი ერთდროული database წვდომა აქვს.

ფუნდამენტური შეხედულება არის ის, რომ **MVCC ნიშნავს რომ კითხვები ჩვეულებრივ არ ბლოკირდებიან** (მკითხველები არ ბლოკავენ writers-ებს — Postgres-ის ერთდროულობის ძირითადი უპირატესობა), ამიტომ ბლოკირება ძირითადად ეხება **ჩაწერებებს და ექსპლიციტურ ბლოკირებას**.

**Row-level locks-ების** გაგება (UPDATE/DELETE-ით აქვემდებარ) და განსაკუთრებით **`SELECT ... FOR UPDATE`** (ხაზების ექსპლიციტური ბლოკირება race conditions-ის თავიდან აცილებისთვის read-modify-write ოპერაციებში — მაგ. უსაფრთხოდ inventory-ის შემცირება ან balance-ის დამუშავება, სადაც ბლოკირების გარეშე ერთდროული ტრანზაქციები შესაძლო გამოიწვიოს არასწორი შედეგები) მნიშვნელოვანია **სისწორისთვის** ერთდროული სცენარიებში.

იმის ცოდნა, რომ **DDL/schema ცვლილებები შეიძლება აიღონ უფრო მძიმე table locks-ები** (შესაძლოა დაბლოკოს queries-ები busy tables-ზე — მნიშვნელოვანი განხილვა migrations გეგმის დროს, თუმცა Postgres-მა გააუმჯობესა ბევრი ALTER-ი რომ იყოს non-blocking) ეხმარება contention-ის თავიდან აცილებაში deployments-ის დროს.

**Lock პრობლემებისა და deadlock-ების თავიდან აცილების** გაგება — ტრანზაქციების მოკლე შენახვა (locks-ების ხანმოკლე ხელში ჩაგდება), locks-ების თანმიმდევრული რიგით აქვემდებარ (deadlock-ების თავიდან აცილება), `FOR UPDATE`-ის განზრახ გამოყენება (და `SKIP LOCKED` queue patterns-ისთვის), და lock contention-ის დიაგნოსტიკა (pg_locks, pg_stat_activity) — ღირებული არის ფუნქციონირებისა და სანდოობის ლოდინში ერთდროულობის პირობებში.

ვინაიდან ერთდროულობა ინერენტული არის რეალურ აპლიკაციებში, და ვინაიდან proper lock-ის გამოყენება (განსაკუთრებით `FOR UPDATE` read-modify-write ოპერაციებში სისწორისთვის, და contention/deadlock-ების თავიდან აცილება) არის ის, რაც აკეთებს ერთდროული database კოდს სწორ და მაღალი ფუნქციონირების, PostgreSQL ბლოკირების გაგება — MVCC-no-read-locks მოდელი, ექსპლიციტური row locking სისწორისთვის, table locks-ები DDL-იდან, და deadlock-ების/contention-ის თავიდან აცილება — ღირებული senior-level ცოდნაა robust ერთდროული აპლიკაციების აგებისთვის და Postgres-ის ოპერირებისთვის load-ის ქვეშ, ხშირად რელევანტური ზოგადი საღვიძე, რომელიც აჩვენებს database ერთდროულობის კონტროლის გაგებას.