PostgreSQL میں locking کیسے کام کرتی ہے؟

Question

Accepted Answer

PostgreSQL **locks** استعمال کرتا ہے بیک وقت رسائی کو مربوط کرنے اور تنازعات سے بچنے کے لیے۔ **MVCC** کی وجہ سے، پڑھنے والی کارروائیوں کو عام طور پر locks کی ضرورت نہیں ہوتی (readers writers کو روکتے نہیں)، لیکن لکھنے والی کارروائیاں row-level locks حاصل کرتی ہیں، اور مختلف lock اقسام کارروائیوں کو مربوط کرتی ہیں۔ Locking کو سمجھنا contention اور deadlocks سے بچنے میں مدد دیتا ہے۔

## MVCC کا مطلب ہے کہ پڑھنا عام طور پر lock نہیں کرتا

```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 (لکھنے اور صریح locking سے)

```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` rows کو lock کرتا ہے تاکہ بیک وقت transactions انہیں modify نہ کر سکیں — read-modify-write کارروائیوں میں race conditions سے بچاتا ہے (مثلاً محفوظ طریقے سے inventory میں کمی)۔

## Lock اقسام اور 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 مسائل اور 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)
```

## یہ کیوں اہم ہے

PostgreSQL locking کو سمجھنا **درست، بہتر کارکردگی والی بیک وقت کارروائیوں والی applications** بنانے کے لیے اہم ہے، اس لیے یہ senior-level علم ہے اہم بیک وقت database رسائی والے نظاموں کے لیے۔

بنیادی نقطہ نظر یہ ہے کہ **MVCC کا مطلب ہے کہ پڑھنا عام طور پر lock نہیں کرتا** (readers writers کو روکتے نہیں — ایک اہم Postgres بیک وقتی فائدہ)، اس لیے locking بنیادی طور پر **لکھنے اور صریح locking** سے متعلق ہے۔

**Row-level locks** کو سمجھنا (UPDATE/DELETE سے حاصل ہوتے ہیں) اور خاص طور پر **`SELECT ... FOR UPDATE`** (صریح طور پر rows کو lock کرنا race conditions سے بچنے کے لیے read-modify-write کارروائیوں میں — جیسے محفوظ طریقے سے inventory میں کمی یا balance کو process کرنا، جہاں locking کے بغیر بیک وقت transactions غلط نتائج دے سکتے ہیں) بیک وقت منظر ناموں میں **درستگی** کے لیے اہم ہے۔

یہ جاننا کہ **DDL/schema تبدیلیاں سنگین table locks لے سکتی ہیں** (ممکنہ طور پر busy tables پر queries کو روکتی ہیں — ایک اہم تحفظ migrations کی منصوبہ بندی کرتے وقت، اگرچہ Postgres نے بہت سی ALTERs کو غیر-blocking بنایا ہے) deployments کے دوران contention سے بچنے میں مدد کرتا ہے۔

**Lock مسائل اور deadlocks سے بچنے** کا طریقہ سمجھنا — transactions کو چھوٹا رکھنا (locks کو مختصر مدت تک رکھنا)، locks کو مسلسل ترتیب میں حاصل کرنا (deadlocks سے بچاتا ہے)، `FOR UPDATE` کو سوچ سمجھ کر استعمال کرنا (اور queue patterns کے لیے `SKIP LOCKED`)، اور lock contention کو تشخیص کرنا (pg_locks, pg_stat_activity) — بیک وقتی کے تحت کارکردگی اور reliability کے لیے قیمتی ہے۔

چونکہ بیک وقتی حقیقی applications میں موجود ہے، اور چونکہ locking کا صحیح استعمال (خاص طور پر read-modify-write کارروائیوں میں درستگی کے لیے `FOR UPDATE`، اور contention/deadlocks سے بچنا) بیک وقت database code کو درست اور بہتر کارکردگی والا بناتا ہے، PostgreSQL locking کو سمجھنا — MVCC-no-read-locks ماڈل، explicit row locking درستگی کے لیے، DDL سے table locks، اور deadlocks/contention سے بچنا — senior-level علم ہے مضبوط بیک وقت applications بنانے اور بوجھ کے تحت Postgres چلانے کے لیے، ایک بار بار متعلقہ تشویش جو database بیک وقتی کنٹرول کی سمجھ کو ظاہر کرتی ہے۔