PostgreSQL 18.6؛ به‌روزرسانی امنیتی فقط روی سرور نیست

انتشار نگهداری چه چیزی را تغییر می‌دهد؟

یادداشت رسمی PostgreSQL 18.6 با تاریخ ۱۳ اوت ۲۰۲۶ مجموعه‌ای از اصلاحات امنیتی و عملیاتی را شرح می‌دهد. در این انتشار، نکات مربوط به سرور و ابزارهایی مثل psql و pg_dump کنار هم آمده‌اند؛ بنابراین نصب patch فقط روی یک ماشین، بررسی کامل زنجیره استفاده را تأمین نمی‌کند. این مقاله راهنمای برنامه‌ریزی نگهداری است، نه دستور ارتقای خودکار. پیش از اقدام، نسخه مناسب شاخه‌ای را که واقعاً اجرا می‌کنید از منبع رسمی بررسی کنید و از نام مشابه بسته‌ها یا شماره‌ای که در یک container قدیمی مانده غافل نشوید.

مستندات می‌گوید برای جابه‌جایی در شاخه 18.X به این نسخه dump/restore لازم نیست؛ ولی این جمله به معنی بی‌نیازی از بررسی داده و تنظیم نیست. یادداشت انتشار برای برخی نصب‌ها تنظیم خروجی logical decoding، رسیدگی به داده رمزگذاری‌شده و بازبینی بعضی ایندکس‌ها را توضیح می‌دهد. نکته مهم این است که 18.5 منتشر نشده است. از فرض وجود همه شماره‌های میانی یا استفاده از یک روش عمومی ارتقای major برای patch پرهیز کنید. بررسی باید روی ویژگی‌های فعال و ابزارهای واقعاً مصرف‌شده محیط شما متمرکز باشد.

کل زنجیره ابزار را ببینید

ابتدا نقشه مصرف را بسازید: سرور اصلی، replica، ابزار backup، ماشین CI، لپ‌تاپ مدیر دیتابیس و imageهای jobهای دوره‌ای. نسخه psql و pg_dump را در همان محیطی بگیرید که واقعاً آن‌ها را اجرا می‌کند. پیشنهاد تحریریه این است که مسئول و روش به‌روزرسانی هر مورد در فهرست نگهداری ثبت شود. اگر فقط نسخه سرور را ثبت کنید، ممکن است ابزار client قدیمی همچنان برای خواندن dump یا اتصال به محیط‌های مختلف مصرف شود. بسته سیستم‌عامل و سرویس مدیریت‌شده نیز روش انتشار و محدودیت مستقل دارند.

برای logical replication، نام slot و plugin را پیش از نگهداری ثبت کنید و با فهرست مجاز نسخه مقصد تطبیق دهید. هر library دلخواه را صرفاً برای رفع خطا مجاز نکنید؛ افزونه باید معتبر و مورد نیاز باشد. اگر از pgcrypto یا extensionهایی که یادداشت انتشار نام برده استفاده می‌کنید، مسیر مرتبط همان نسخه را دقیق بخوانید و بازبینی را در محیط آزمایش انجام دهید. کد این مقاله فقط اطلاعات را می‌خواند و تغییری ایجاد نمی‌کند؛ بعضی نماها یا تنظیمات ممکن است به نقش دارای مجوز کافی نیاز داشته باشند.

قبل از نگهداری، نسخه پشتیبان و روش بازیابی آزموده‌شده داشته باشید و تست‌های برنامه را روی نسخه مقصد اجرا کنید. ارتباط، authentication، خواندن و نوشتن معمول، تهیه backup و بازیابی در محیط جدا را در چک‌لیست بیاورید. اگر migration داده یا reindex خاصی لازم است، آن را با زمان و مسئول مستقل برنامه‌ریزی کنید. شعار «patch است و مشکلی ندارد» جای شواهد را نمی‌گیرد. هم‌زمان، عملیات حساس را بدون اینکه واقعاً ویژگی مربوط در سامانه فعال باشد به همه نصب‌ها تعمیم ندهید.

SELECT version();
SHOW server_version;
SELECT extname,extversion FROM pg_extension ORDER BY extname;
SELECT slot_name,plugin,slot_type,active
FROM pg_replication_slots ORDER BY slot_name;
SELECT name,setting FROM pg_settings
WHERE name IN ('output_plugin_libraries','shared_preload_libraries');

-- On each backup/CI machine, separately run:
-- psql --version
-- pg_dump --version

بعد از نصب چه شواهدی لازم است؟

بعد از به‌روزرسانی، نسخه اجراشده را از خود اتصال دیتابیس و ابزار client بخوانید و replication، error log و jobهای backup را کنترل کنید. گزارش باید تغییرهای اعمال‌شده، تست‌های موفق و موارد باقیمانده را مشخص کند. اگر مشکل سازگاری دیده شد، برنامه پاسخ و بازیابی باید از قبل روشن باشد؛ rollback یک دیتابیس همیشه مانند تعویض image ساده نیست. ارزش این انتشار برای تیم، تبدیل یک خبر امنیتی به نگهداری مستند و قابل بررسی تمام مسیر داده است، نه صرفاً تغییر عدد نسخه در فهرست دارایی‌ها.

تاریخ انتشار منبع: 2026-08-13. توضیح‌ها و پیشنهادهای اجرایی این مطلب، تحلیل تحریریه دانشنامه لیان هستند.منابع: PostgreSQL — 18.6 release notes · PostgreSQL — Backup and restore · PostgreSQL — Versioning policy

این مطلب بازنویسی تحلیلی دانشنامه لیان بر پایه منبع اصلی است.مشاهده منبع اصلی