題干與適用場景
PostgreSQL 18.4 是 18.x 的小版本更新，官方說明 18.x 之間升級不需要 dump/restore；版本策略建議執行目前小版本。題目要求你把安全公告轉成可執行的生產變更：辨識受影響路徑、安排滾動升級、驗證連線與複製狀態，並保留回滾邊界。
面試官考察點
- 能否區分小版本修復與大版本遷移的風險與工具。
- 能否從 CVE 描述追到實際暴露面、權限與流量路徑。
- 能否設計主從、連線池、擴充套件與備份的升級順序。
- 能否用證據驗證修復生效，而不是只看程序啟動成功。
回答前需要釐清的問題
先確認目前版本、部署拓撲、是否使用邏輯複製或讀副本、可接受的連線中斷窗口，以及受影響功能是否啟用。還要確認擴充套件、用戶端驅動、備份工具與託管服務的支援矩陣，以及回滾時是否允許降回舊二進位檔。
30 秒回答框架
我會按「盤點—預演—升級—驗證—收尾」回答。先把公告缺陷映射到實際入口與權限，再在影子或備庫演練。生產時先升級副本、切換流量，再升級原主庫；連線池設定排空與重連。驗證版本、複製延遲、錯誤率、關鍵查詢與安全回歸，最後保留舊套件、備份與明確回滾截止點。
分步驟深入解答
1. 評估暴露面
閱讀 18.4 release notes，列出啟動封包處理、記憶體配置、訂閱命令與物件名稱引用等修復。逐項檢查應用是否允許不可信連線、是否執行相關管理命令，以及資料庫角色能否到達這些路徑。把「可觸發」與「已被利用」分開記錄。
2. 預演與相容性
在與生產相同的映像檔與參數上還原備份，跑應用回歸、擴充套件載入、遷移工具與長交易情境。確認小版本升級不需 dump/restore，但仍要校驗發行套件、動態庫與託管平台的建置來源。記錄基線：連線成功率、查詢延遲、複製延遲與 WAL 增長。
3. 安全滾動升級
先從只讀副本開始，排空連線並升級二進位檔，確認副本追平後逐個切換。主庫切換前暫停高風險管理任務，確保連線池不會無限保留舊連線。升級原主庫並重新加入複製，所有步驟設定逾時與人工確認點。
4. 驗證與回滾
檢查 server_version、啟動日誌、複製狀態、錯誤碼與關鍵讀寫路徑；對公告觸發條件做最小化安全回歸。若失敗，優先切回已驗證的舊副本或還原備份，不在不相容的混合版本上長時間運行。升級後保留證據、關閉臨時權限並更新資產清單。
高品質示範回答
我會先鎖定目前 18.x 小版本與拓撲，再把 18.4 公告的每個修復映射到真實入口。針對啟動封包、記憶體配置與訂閱物件名稱等路徑，我會檢查是否存在不可信輸入、對應角色權限與實際呼叫。小版本無需 dump/restore，但擴充套件、映像檔與託管平台仍需相容性確認。
升級採副本優先：在同版本基線環境演練，記錄連線成功率、查詢延遲、複製延遲與 WAL 增長；生產排空副本連線、升級並確認追平，再切換流量，最後升級原主庫。驗證版本、日誌、複製與關鍵查詢，並對修復路徑做安全回歸。失敗時切回已驗證副本或備份，保留舊套件與回滾截止點，避免長時間混跑未驗證版本。
常見錯誤
- 把小版本升級當成大版本遷移，盲目執行 dump/restore 或忽略擴充套件相容性。
- 只檢查版本字串，不檢查複製、連線池、關鍵查詢與安全觸發路徑。
- 主庫先升級，導致所有副本失去快速切換能力。
- 沒有回滾截止點，讓新舊二進位檔長期混合運行。
追問及應對
為什麼公告中的「可當機」問題也要按安全事件處理？
遠端可觸發當機會影響可用性，若伴隨記憶體越界或資訊暴露還可能擴大影響。應按入口、權限、可利用性與監控證據分級，不要只看是否執行了程式碼。
如何協調連線池？
先標記實例不可接收新連線，排空或設定短連線生命週期，再升級並健康檢查。切換後讓連線池重新建立連線，監控重試風暴與交易中斷。
什麼時候不能直接回滾二進位檔？
若升級期間執行不可逆的資料或目錄格式變更，或複製拓撲包含不相容版本，就不能只替換二進位檔。此時要用已驗證備份、相容副本或完成遷移後再決定回退。