Ahsan Hadi در گزارشی عملی، ارتقای درجا یک Node از PostgreSQL 17.10 به 18.6 را همراه با standby تحت مدیریت Patroni آزمایش کرده است. محیط آزمایش، یک cluster سهNodeای Spock روی دو ماشین مجازی Rocky Linux ARM64 بوده است. برخلاف روش rolling که برای جایگزینی هر Node به سرور تازه نیاز دارد، این روش همان Node را ارتقا می‌دهد.
منظور از نبود downtime، متوقف‌نشدن خود Node نیست. هنگام ارتقا، آن Node خاموش می‌شود، اما در cluster از نوع multi-master، بقیه همچنان نوشتن را می‌پذیرند و برنامه یک endpoint قابل نوشتن دارد. نویسنده برای این روند حداقل سه Node را لازم می‌داند تا هنگام ارتقای یکی، دو مورد دیگر فعال بمانند.
روند کار با خارج‌کردن ترافیک Node و اطمینان از به‌روز بودن subscriptionها آغاز می‌شود. سپس Patroni در حالت pause قرار می‌گیرد و ابتدا standby و بعد Node خاموش می‌شوند. پس از آماده‌سازی data directory جدید و تنظیم Spock، ابزار pg_upgrade فایل‌های داده را با hard link، به‌جای کپی‌کردن، منتقل می‌کند. encoding و وضعیت checksum باید با cluster قبلی یکسان باشند؛ PostgreSQL 18 به‌صورت پیش‌فرض checksum را فعال می‌کند. نسخهٔ Spock نیز باید در دو سمت یکسان باشد و DDL replication طی ارتقا غیرفعال بماند.
مهم‌ترین مشکل آزمایش، منتقل‌نشدن Replication Originهای Spock بود. هرچند logical slotها از مبدأ PostgreSQL 17 حفظ شدند، Node ارتقایافته تغییرات دیگر Nodeها را اعمال نمی‌کرد؛ درحالی‌که آن‌ها همچنان وضعیتش را سالم گزارش می‌کردند. راه‌حل، بازسازی هر Replication Origin در موقعیتی بود که provider آخرین تأیید آن Node را ثبت کرده بود. نویسنده پس از اصلاح، نوشتن در هر دو جهت را آزمایش کرد. برای مبدأ PostgreSQL 15 یا 16، logical slotها حفظ نمی‌شوند و subscriptionهای دیگر Nodeها به این Node به همگام‌سازی کامل نیاز دارند.
بازگرداندن مدیریت به Patroni نیز صرفاً با تغییر مسیرها تمام نشد: فرایند Patroni به restart نیاز داشت و system identifier تازه با مقدار قبلی etcd ناسازگار بود. نویسنده با توقف Patroni و حذف رکورد cluster از etcd، اجازه داد نمونهٔ در حال اجرا دوباره پذیرفته شود.
standby نیز باید از Node ارتقایافته بازسازی شود، چون نمی‌تواند primary را در عبور از نسخهٔ اصلی دنبال کند. جمع‌بندی گزارش این است که وضعیت ظاهراً سالم کافی نیست: بازیابی پیشرفت Spock و آزمایش نوشتن دوطرفه باید پیش از رفتن سراغ Node بعدی انجام شوند.
