PostgreSQL 19 Beta 4: اختبر الترقية لا قائمة الميزات

PostgreSQL 19 Beta 4 مادة للاختبار، وليست توصية بالترقية. نشر مشروع PostgreSQL النسخة في 24 سبتمبر 2026، وذكر أن Release Candidate مخطط له في أوائل أكتوبر، مع احتمال وصول الإصدار العام لاحقًا في أكتوبر. ويحذر الإعلان نفسه من إمكان تغير السلوك والواجهات، بينما تنصح إرشادات Beta الرسمية صراحة بعدم استخدامها في الإنتاج.

هذا السياق مهم لأن Beta 4 أزالت عدة ميزات ظهرت في مراحل سابقة: استعلامات Property Graph عبر SQL/PGQ، وتفعيل Data Checksums وتعطيلها أثناء التشغيل، وتحديثات وحذف `FOR PORTION OF` الزمنية، وأوامر دمج وتقسيم الأقسام، وبعض دوال استخراج DDL. لذلك يجب أن تبدأ مراجعة الجاهزية مما تحتويه Beta 4 فعليًا، لا من عروض قديمة أو مقالات عن Beta سابقة أوخريطة طريق محفوظة في الذاكرة.

السؤال المفيد ليس هل قائمة الميزات جذابة، بل هل يتصرف Schema والامتدادات وDrivers وأدوات التشغيل والاستعلامات الممثلة لنظامك بصورة صحيحة على النسخة المرشحة، وهل تستطيع إنتاج أدلة كافية لاتخاذ قرار ترقية بعد GA.

ثبّت هدف الاختبار وافتراضاته

أنشئ بيئة PostgreSQL 19 Beta 4 معزولة من Image أوPackage قابل لإعادة البناء، وسجّل Build وConfiguration بدقة، ثم استعد نسخة من البيانات تشبه الإنتاج بعد إزالة البيانات الحساسة. لا توصل تطبيقات حية إليها. احفظ إصدار PostgreSQL المصدر وإصدارات الامتدادات ومزود Collation وLocale و`shared_preload_libraries` وإعدادات المصادقة وكل Parameter غير افتراضي.

احصر الكود الذي يعتمد على ميزات أزيلت أوسلوك تغير. تعرض ملاحظات الإصدار تغييرات توافق مثل فرض `standard_conforming_strings = on`، وإزالة RADIUS، وتعطيل JIT افتراضيًا، ورفع القيمة الافتراضية لـ`max_locks_per_transaction`، وإعادة تسمية حقول إحصائية. كما يرفض `pg_upgrade` في PostgreSQL 19 ترقية Clusters تحتوي Operator Classes معينة ومشكلة من `btree_gist` لأنواع `inet` أو`cidr`. هذه فحوص ملموسة وليست تفاصيل هامشية.

نفّذ آلية الترحيل الحقيقية التي ستستخدمها: `pg_upgrade` أوDump/Restore أوLogical Replication. قس زمن كل مرحلة واحفظ Logs. نجاح التشغيل أول بوابة فقط؛ تحقق من أعداد الصفوف والقيود والفهارس وSequences والصلاحيات والكائنات المولدة وصحة الامتدادات قبل إعادة تشغيل الحمل.

أعد تشغيل الاستعلامات الحقيقية وقارن الخطط

اجمع حملًا ممثلًا بدل مجموعة Happy Paths مصطنعة. ضمّن عبارات OLTP عالية التكرار، والاستعلامات التحليلية المكلفة، والمعاملات كثيفة Locks، وBackground Jobs، وترحيلات Schema، والحالات الطرفية كثيرة الفشل. أزل الأسرار والبيانات الشخصية، لكن احتفظ بتوزيعات Parameters التي تؤثر في Selectivity.

لكل استعلام مهم، خزّن Latency Percentiles والصفوف المعادة وBuffer Activity وTemporary Files وخطة `EXPLAIN (ANALYZE, BUFFERS, WAL)` كاملة على Major الحالي وBeta 4. يضيف PostgreSQL 19 تغييرات في Planner وExecutor، منها تحويلات أوسع إلى Anti Join، وإمكان التجميع قبل بعض Joins، وتحسين فحوص Foreign Keys، كما يضيف تقرير I/O إلى `EXPLAIN ANALYZE` للـAsynchronous I/O. التحسن يعتمد على الحمل؛ تغير الخطة ليس فوزًا ولاRegression حتى يُقاس.

اربط الحدود بأهداف الخدمة. ارفض المرشح مثلًا إذا ارتفع p95 لاستعلام حرج فوق نسبة متفق عليها، أوتجاوزت Temporary Bytes ميزانية التخزين، أوظهرت Plan Instability بين فئات Parameters. احتفظ بالخطط الخام ليشرح الفريق النتيجة بدل الجدال حول المتوسطات.

عامل REPACK كتجربة موارد وأقفال

يعيد أمر `REPACK` الجديد كتابة الجدول لاسترجاع المساحة، ويمكنه ترتيب الصفوف بحسب فهرس. من دون `CONCURRENTLY` يأخذ `ACCESS EXCLUSIVE` Lock طوال العملية. ومع `CONCURRENTLY` ينسخ PostgreSQL الجدول والفهارس، ويلتقط التغييرات المتزامنة عبر Logical Decoding، ويطبقها، ثم يحتفظ بالقفل الحصري غالبًا لمرحلة تبديل الملفات النهائية.

ليست هذه عملية Online مجانية. تقول الوثائق إن إعادة الكتابة العادية تحتاج مساحة حرة تعادل الجدول وفهارسه على الأقل؛ وقد يبلغ الذروة عند Sequential Scan مع Sort قرابة ضعفي حجم الجدول إضافة إلى الفهارس. ويمكن أن تضيف DML المتزامنة مساحة مؤقتة أخرى. وقد تتسبب DDL أثناء العملية في فشلها، وتحذر الوثائق الحالية من أن Concurrent Repack ليست MVCC-safe. وتحتوي Beta 4 نفسها إصلاحات متعددة لانهيارات REPACK والفهارس غير الصالحة وMaterialized Views والصلاحيات وتقارير الخطأ.

ابنِ مصفوفة اختبار حول أكبر الجداول وأكثرها نشاطًا. قس Peak Temporary Storage وWAL Generation وReplica Lag وI/O Saturation وLock Wait وزمن الاستعلام أثناء النسخ وتوقف Final Swap. احقن DDL وإلغاء العملية وضغط القرص وانقطاع Client. تحقق من الجدول وكل فهرس بعد العملية، ثم شغّل `ANALYZE` أواستخدم الخيار الموثق حتى يرى Planner الترتيب المادي الجديد.

بوابة REPACK =
  مساحة مؤقتة كافية
  AND تأخر Replica محدود
  AND قفل تبديل محدود
  AND سلامة الجدول والفهارس مثبتة
  AND مسار تنظيف بعد الفشل مجرّب

لا تحول REPACK إلى سياسة صيانة إنتاجية آلية قبل أن تجتاز النسخة النهائية ومساحة التخزين ومسار الفشل هذه البوابة.

اختبر التكرار ومسارات Read-your-writes

يمكن لـPostgreSQL 19 تكرار قيم Sequences عبر Logical Replication، ويمكنه تمكين Logical Replication بلا Restart عندما يكون `wal_level` مضبوطًا أصلًا على `replica`. كما يقدم أمر انتظار يجعل Standby ينتظر حتى يعيد تشغيل التغييرات إلى نقطة محددة، لدعم نمط Read-your-writes. تمس هذه الميزات حدود صحة البيانات، لذا اختبرها تحت التعطل.

أنشئ Publication وSubscription مشابهتين للإنتاج. نفّذ Inserts تخصص قيم Sequence، وتغييرات صريحة للSequence، وانقطاعات شبيهة بـFailover، وإعادة المزامنة. تحقق من عدم إمكان تصادم IDs المولدة بعد تبديل الدور، ومن أن Monitoring يفصل أخطاء Table Sync عن Sequence Errors. تتضمن Beta 4 إصلاحات للمزامنة الأولية من إصدارات PostgreSQL أقدم ولاكتشاف تعارضات Logical Replication؛ وهذه إشارة لاختبار تلك المسارات بالتحديد.

لقراءات Standby، قس الزمن من Commit Token إلى حالة قابلة للقراءة. اختبر Cancellation وTimeout وإعادة تشغيل Replica وتأخرها. يحتاج التطبيق سياسة محدودة: الانتظار، أوFallback إلى Primary، أوإجابة قابلة لإعادة المحاولة، أوقبول بيانات قديمة لطلب محدد. لا يختار أمر قاعدة البيانات هذه المقايضة نيابة عن المنتج.

اختبر التشغيل لا SQL فقط

نفّذ Backup وPoint-in-time Recovery بالأدوات وسياسات الاحتفاظ وObject Storage نفسها المستخدمة في الإنتاج. استعد إلى Host جديد وأثبت اتصال التطبيق. اختبر Monitoring Exporters وConnection Poolers وCDC Connectors وأطر Migrations وORM Drivers ووظائف الصيانة ذات الصلاحيات. راجع Dashboards للحقول الإحصائية المعاد تسميتها أوالمقسمة بدل افتراض أن البيانات المفقودة تساوي صفرًا.

يغير PostgreSQL 19 ترتيب Autovacuum بنظام Scoring، ويسمح بـParallel Workers لصيانة Indexes. أعد تشغيل Tables كثيفة التغيير وراقب Dead Tuples وFreeze Age واستخدام Workers وتنافس I/O واحتمال حرمان الجداول الصغيرة. وإذا كان JIT مهمًا للأحمال التحليلية، فقارن السلوك الجديد المعطل افتراضيًا مع Configuration مفعلة صراحة ومقاسة بدل إعادة القيمة القديمة بلا دليل.

تدخل اختبارات الأمان في الدورة نفسها: طرق المصادقة، وتحذيرات انتهاء كلمات المرور، والتحقق من TLS، وRole Inheritance، وRow-level Security، ودوال `SECURITY DEFINER`، وCredentials النسخ الاحتياطي. التوافق خاصية تطبيق وخاصية تشغيل في الوقت نفسه.

اجعل بوابة الاعتماد قائمة على الدليل

اختم بـScorecard يسمي Owner وDataset وCommand وThreshold وResult ورابط الدليل لكل بوابة. يجب أن يشمل على الأقل زمن الترحيل، وتوافق التطبيق، وزمن الاستعلامات الحرجة، وPlan Regressions، وذروة موارد REPACK، وصحة التكرار، وReplica Lag، واستعادة Backup، ودعم الامتدادات، وتغطية Observability، وزمن Rollback.

نجاح Beta لا يعني السماح بنشر Beta. بل يقلل الغموض قبل Release Candidate ويمنح Maintainers وقتًا لمعالجة المشكلات. أعد تشغيل المجموعة على Release Candidate ثم على حزم GA نفسها التي ستنشرها؛ فقد تتحرك الميزات والإصلاحات.

أقوى نتيجة من PostgreSQL 19 Beta 4 ليست قائمة Syntax جديدة، بل مجموعة أدلة قابلة للتكرار: ما الميزات المتبقية، وأي افتراضات انكسرت، وكم تستهلك الصيانة من Headroom، وهل يحافظ التكرار على الصحة، وكم يحتاج الفريق للعودة إلى حالة سليمة. هذا ما يحول ترقية Major مستقبلية من أمل إلى قرار هندسي.

إعداد: Noor Yasser