PostgreSQL 19: أهمّ ميزة فيها هي أكثرها مللاً

كل سبتمبر تصدر نسخة كبيرة من PostgreSQL، وكل سبتمبر تُكتب القائمة نفسها: ميزات الأداء أولاً، ثم أدوات المطوّر، ثم شيء عن النسخ المنطقي في الآخر. هذا العام تستحقّ القائمة أن تُقلَب رأساً على عقب.

أهمّ ما في PostgreSQL 19 ليس أسرع استعلام ولا أذكى مخطّط تنفيذ، بل سطر يبدو إدارياً بحتاً: النسخ المنطقي صار ينسخ قيم المتتاليات (Sequences). هذه الجملة الباهتة تنهي واحدة من أكثر لحظات الترقية رعباً في تشغيل قواعد البيانات — وتصل تحديداً في الموسم الذي تموت فيه PostgreSQL 14.

ملاحظة قبل البدء: وقت كتابة هذا المقال كانت النسخة 19 في مرحلة الإصدارات التجريبية، والنسخة المستقرّة متوقّعة خلال سبتمبر أو أكتوبر 2026. لا تعتمد عليها في الإنتاج قبل صدور النسخة النهائية.

المشكلة التي عاشت عشرين عاماً

لفهم لماذا هذا مهمّ، تخيّل السيناريو الذي تمرّ به كل شركة تريد ترقية قاعدة بياناتها بلا توقّف: تبني خادماً جديداً بالنسخة الأحدث، وتشغّل نسخاً منطقياً من القديم إليه، وتنتظر حتى يلحق، ثم تحوّل التطبيق إليه في ثوانٍ.

الخطوة المفقودة كانت دائماً هنا. النسخ المنطقي كان ينقل صفوف الجداول ولا ينقل حالة المتتاليات. أي أن جدول orders في الخادم الجديد يحتوي على مليون صف، بينما عدّاد orders_id_seq عنده ما زال عند 1.

النتيجة بعد التحويل مباشرة: أول عملية إدراج تحاول استخدام المعرّف رقم 1، فتصطدم بصفّ موجود. ثم الثاني، ثم الثالث. التطبيق يتوقّف عن قبول الطلبات في اللحظة الأسوأ الممكنة — بعد أن أعلنت للجميع أن الترقية نجحت.

الحلّ المعتاد كان سكربتاً يدوياً يمرّ على كل متتالية في قاعدة البيانات ويضبطها يدوياً بـsetval قبل التحويل. يعمل، لكنه طقس هشّ: متتالية واحدة منسيّة في مخطّط فرعي تكفي لتخريب العملية كلها، والخطأ لا يظهر إلا بعد فوات الأوان.

ما الذي تغيّر في 19 بالضبط

التحسينات في هذا المجال جاءت كحزمة متكاملة لا كميزة واحدة:

• نسخ قيم المتتاليات ضمن النسخ المنطقي.
• ALL SEQUENCES في تعريف المنشور (Publication)، فتُدرج كل المتتاليات دفعة واحدة بدل تعدادها يدوياً — وهذا ما يقتل خطأ «واحدة منسيّة».
• تقارير أخطاء مزامنة المتتاليات، بدل الفشل الصامت.
• تفعيل النسخ المنطقي بلا إعادة تشغيل الخادم حين يكون wal_level مضبوطاً على replica.
• effective_wal_level، إعداد جديد يخبرك بما هو ساري المفعول فعلاً لا بما كتبته في ملف الإعدادات.

آخر نقطتين تستحقّان انتباهاً خاصاً. تفعيل النسخ المنطقي كان يتطلّب إعادة تشغيل الخادم، وهو ما يعني نافذة توقّف مجدولة قبل أن تبدأ الترقية التي تحاول تفاديها أصلاً. أمّا effective_wal_level فهو اعتراف صريح بمشكلة قديمة: الفجوة بين الإعداد المكتوب والإعداد الفعلي كانت مصدراً مزمناً لساعات تشخيص ضائعة.

الميزات التي تُلغي خطوة يدوية أهمّ من الميزات التي تسرّع خطوة آلية. الخطوة الآلية البطيئة تكلّفك ثواني؛ الخطوة اليدوية المنسيّة تكلّفك انقطاعاً كاملاً.

التوقيت ليس صدفة

في 12 نوفمبر 2026 تتوقّف PostgreSQL 14 عن تلقّي التحديثات نهائياً. لا إصلاحات أمنية، لا إصلاحات أخطاء.

هذا يعني أن آلاف الفرق التي تشغّل النسخة 14 في الإنتاج أمامها نافذة من شهرين تقريباً لتخطيط ترقية كبرى. والمفارقة اللطيفة أن الأداة التي تجعل هذه الترقية أقلّ رعباً تصل في الشهر نفسه الذي يبدأ فيه العدّ التنازلي.

لو كنت تشغّل 14، فالقرار العملي ليس «هل أرقّي؟» بل «إلى أين؟». الترقية إلى نسخة مستقرّة ومجرَّبة كـ17 أو 18 خيار محافظ معقول، وانتظار استقرار 19 بضعة أشهر قبل القفز إليها ممارسة سليمة — النسخ الكبرى عادةً تحتاج إصدارين ثانويين قبل أن يطمئنّ إليها المشغّلون.

بقيّة النسخة: ما يستحقّ الانتباه فعلاً

الميزة	لمن تهمّ	لماذا
pg_plan_advice	فرق تعاني استعلامات تتغيّر خططها فجأة	امتداد لتثبيت قرارات المخطّط والتحكّم فيها بدل الاعتماد على الحظّ
تنظيف متوازٍ للفهارس	جداول ضخمة كثيرة التحديث	الـautovacuum صار يستخدم عمليات متوازية لتنظيف فهارس الجدول
REPACK مدمج	من يستخدم pg_repack كامتداد خارجي	أمر أصلي داخل القاعدة بدل تبعية خارجية
WAIT FOR	تطبيقات تقرأ من النسخ الاحتياطية	ينتظر حتى تلحق النسخة بنقطة محدّدة — يحلّ «اقرأ ما كتبتَه للتوّ»
تفعيل الـchecksums أثناء التشغيل	قواعد إنتاجية قديمة	تشغيل أو إيقاف تدقيق سلامة البيانات بلا إيقاف الخادم
FOR PORTION OF	أنظمة تحفظ تاريخ التغيّرات	تحديث وحذف زمنيان على نطاق محدّد من الصلاحية

الميزة الأولى تستحقّ سطرين إضافيين. عدم استقرار خطط التنفيذ من أكثر المشاكل إزعاجاً في الإنتاج: استعلام يعمل في ملّي ثانية لشهور، ثم يقرّر المخطّط ذات صباح مسار تنفيذ مختلفاً فيصير أبطأ ألف مرة — بلا أي تغيير في الكود. وجود آلية رسمية لتثبيت القرار يحوّل هذه المشكلة من «انتظر وادعُ» إلى شيء قابل للإدارة.

أمّا WAIT FOR فيحلّ مأزقاً شائعاً في التطبيقات التي توزّع القراءة على النسخ الاحتياطية: المستخدم يحفظ بياناته ثم يُعاد توجيهه لصفحة تقرأ من نسخة لم تلحق بعد، فيرى بياناته القديمة ويظنّ أن الحفظ فشل.

فخّ عملي في التحديثات الأخيرة

بعيداً عن النسخة 19، هناك تفصيل يستحقّ دقيقتين من وقتك إن كنت حدّثت مؤخّراً.

تحديثات أغسطس 2026 (18.6 و17.11 و16.15 و15.19 و14.24) أصلحت 28 ثغرة أمنية وأكثر من 110 خطأ. لكن إن كان لديك جداول تستخدم فهارس GIN، فافحص قيمة reltuples فيها بعد التحديث: خطأ سابق في بناء فهارس GIN المتوازية كان قد يترك القيمة بحالة غير صالحة — تصل أحياناً إلى ما لا نهاية أو إلى قيمة غير رقمية.

الأثر خبيث لأنه صامت: الـautovacuum والـautoanalyze يتوقّفان عن معالجة الجدول تماماً، بلا رسالة خطأ. والنتيجة تتراكم على مدى أسابيع في صورة تضخّم في الجدول وخطط تنفيذ تسوء تدريجياً بلا سبب ظاهر. فحصها استعلام واحد، وإصلاحها ANALYZE واحد.

ولاحظ أيضاً أن الترقيم قفز من 18.4 إلى 18.6 مباشرة: النسخة 18.5 لم تُشحن بسبب تراجع في الأداء اكتُشف قبل الإصدار. هذا في الواقع خبر مطمئن لا مقلق — يعني أن الاختبار قبل الإصدار يعمل.

أسئلة شائعة

هل أحتاج الترقية إلى 19 فوراً لأستفيد من نسخ المتتاليات؟

نعم لهذه الميزة تحديداً، لأنها تغيير في نواة النسخ المنطقي وليست امتداداً. لكن انتبه إلى نقطة مهمة: في ترقية كبرى بالنسخ المنطقي، النسخة الهدف هي التي تحدّد. أي أن الترقية من 16 إلى 19 تستفيد منها، بينما الترقية من 14 إلى 17 ما زالت تحتاج ضبط المتتاليات يدوياً.

ما الفرق بين pg_upgrade والنسخ المنطقي للترقية؟

pg_upgrade أسرع بكثير ويتعامل مع الملفّات مباشرة، لكنه يتطلّب إيقاف قاعدة البيانات طوال العملية — دقائق إلى ساعات حسب الحجم. النسخ المنطقي أبطأ وأعقد إعداداً، لكن التوقّف فيه يقتصر على لحظة التحويل نفسها. القاعدة العملية: pg_upgrade إن كانت نافذة الصيانة متاحة، والنسخ المنطقي إن لم تكن.

هل ما زال هناك سبب لاستخدام PostgreSQL 14؟

لا بعد 12 نوفمبر 2026. تشغيل نسخة خارج الدعم يعني أن أي ثغرة تُكتشف بعد ذلك التاريخ لن تُصلَح لك أبداً، ومع الوقت تتوقّف الامتدادات والأدوات المحيطة عن دعمها. التكلفة الحقيقية للتأجيل ليست أمنية فقط، بل أن الترقية تصير أصعب كلّما تراكمت النسخ بينك وبين المدعوم.

الخلاصة

PostgreSQL 19 ليست نسخة استعراضية، وهذا تحديداً ما يجعلها مهمّة. الميزة التي ستغيّر يومك فعلاً ليست الأسرع بل الأقلّ إثارة: نسخ منطقي صار ينقل المتتاليات، فتحوّلت ترقية بلا توقّف من طقس يتقنه المتخصّصون إلى عملية عادية.

وإن كنت تشغّل PostgreSQL 14، فالتاريخ الذي يجب أن يكون في تقويمك ليس تاريخ صدور 19، بل 12 نوفمبر 2026. الأول فرصة، والثاني موعد نهائي — والفرق بينهما هو الفرق بين ترقية مخطّطة وترقية مستعجلة تحت ضغط ثغرة مكتشفة.