كيف يعمل القفل (Locking) في PostgreSQL؟

Question

Accepted Answer

يستخدم PostgreSQL **الأقفال (locks)** لتنسيق الوصول المتزامن ومنع التضارب. بفضل **MVCC**، عادةً لا تحتاج عمليات القراءة إلى أقفال (القراء لا يحجبون الكتاب)، لكن عمليات الكتابة تحصل على أقفال على مستوى الصفوف، وأنواع القفل المختلفة تنسق العمليات. فهم الأقفال يساعد في تجنب التنافس والجمودات.

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

## أقفال مستوى الصف (من عمليات الكتابة والقفل الصريح)

```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` تقفل الصفوف بحيث لا تستطيع المعاملات المتزامنة تعديلها — مما يمنع حالات التسابق في عمليات القراءة-التعديل-الكتابة (مثل تقليل المخزون بأمان).

## أنواع الأقفال والأقفال على مستوى الجدول

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

## تجنب مشاكل الأقفال والجمودات

```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 مهم لبناء **تطبيقات متزامنة صحيحة وفعالة**، لذلك فهو معرفة قيمة على مستوى كبار المهندسين للأنظمة التي تحتوي على وصول متزامن كبير لقاعدة البيانات.

الفكرة الأساسية هي أن **MVCC يعني أن القراءة عادةً لا تحتاج إلى قفل** (القراء لا يحجبون الكتاب — وهي ميزة تزامن رئيسية في Postgres)، لذلك يتعلق القفل بشكل أساسي بـ **الكتابة والقفل الصريح**.

فهم **أقفال مستوى الصف** (التي يتم الحصول عليها بواسطة UPDATE/DELETE) وخاصة **`SELECT ... FOR UPDATE`** (قفل الصفوف بشكل صريح لمنع حالات التسابق في عمليات القراءة-التعديل-الكتابة — مثل تقليل المخزون بأمان أو معالجة الرصيد، حيث بدون القفل يمكن للمعاملات المتزامنة أن تسبب نتائج غير صحيحة) مهم للحصول على **الصحة** في السيناريوهات المتزامنة.

معرفة أن **تغييرات DDL/المخطط يمكن أن تأخذ أقفال جدول أثقل** (قد تحجب الاستعلامات على الجداول المشغولة — اعتبار مهم عند التخطيط للهجرات، رغم أن Postgres حسّن العديد من ALTERs ليكون غير محجوب) يساعد في تجنب التنافس أثناء النشر.

فهم كيفية **تجنب مشاكل الأقفال والجمودات** — إبقاء المعاملات قصيرة (الاحتفاظ بالأقفال لفترة وجيزة)، الحصول على الأقفال بترتيب متسق (منع الجمودات)، استخدام `FOR UPDATE` بحكمة (و `SKIP LOCKED` لأنماط الطابور)، وتشخيص تنافس الأقفال (pg_locks، pg_stat_activity) — قيمة للأداء والموثوقية تحت التزامن.

بما أن التزامن متأصل في التطبيقات الحقيقية، وبما أن الاستخدام الصحيح للأقفال (خاصة `FOR UPDATE` للصحة في عمليات القراءة-التعديل-الكتابة، وتجنب التنافس/الجمودات) هو ما يجعل كود قاعدة البيانات المتزامن صحيحاً وفعالاً، فإن فهم قفل PostgreSQL — نموذج MVCC بدون أقفال القراءة، القفل الصريح للصفوف من أجل الصحة، أقفال الجدول من DDL، وتجنب الجمودات/التنافس — معرفة قيمة على مستوى كبار المهندسين لبناء تطبيقات متزامنة قوية وتشغيل Postgres تحت الحمل، وهي مشكلة ذات صلة متكررة تثبت فهم التحكم في التزامن في قاعدة البيانات.