PostgreSQL 18.3 Patch ด่วน

ทำไมถึงต้องออก Patch นอกรอบ?

โดยปกติ PostgreSQL จะออก Minor Release ตามรอบทุกไตรมาส แต่ครั้งนี้เป็น Out-of-cycle Release ที่ออกเร่งด่วนภายใน 14 วัน หลังจากเวอร์ชัน 18.2 ถูกปล่อยออกมา สาเหตุหลักคือ:

• บั๊กบางตัวทำให้ Standby Server หยุดทำงาน — กระทบระบบ High Availability โดยตรง
• บั๊กบางตัวทำให้ แอปพลิเคชัน Crash เมื่อใช้ฟังก์ชัน Text Search หรือ JSON
• บั๊กบางตัวทำให้ Query ให้ผลลัพธ์ผิด โดยไม่แจ้ง Error — อันตรายที่สุดเพราะตรวจจับยาก

9 บั๊กที่ถูกแก้ไขใน Patch นี้

1. Standby Server หยุดทำงาน — "could not access status of transaction"

บั๊กนี้ร้ายแรงที่สุด เพราะทำให้ Standby Server (Read Replica) หยุดทำงาน โดยแสดง Error ว่า "could not access status of transaction" ซึ่งหมายความว่าระบบ Disaster Recovery และ High Availability จะใช้งานไม่ได้จนกว่าจะ Patch

2. substring() Encoding Error บนข้อความ Non-ASCII

ฟังก์ชัน substring() ให้ผลลัพธ์ผิดเมื่อใช้กับข้อความที่ไม่ใช่ ASCII เช่น ภาษาไทย ภาษาจีน ภาษาญี่ปุ่น — เป็น Regression จากการแก้ไขช่องโหว่ CVE-2026-2006 ในเวอร์ชันก่อนหน้า สำหรับระบบ ERP ที่เก็บข้อมูลภาษาไทย บั๊กนี้อาจทำให้รายงานแสดงข้อมูลผิดพลาดโดยไม่รู้ตัว

3. pg_trgm strict_word_similarity() Crash

ฟังก์ชัน strict_word_similarity() ใน Extension pg_trgm ที่ใช้สำหรับ Fuzzy Text Search ทำให้ PostgreSQL Crash ทันที — เป็น Regression จากการแก้ไข CVE-2026-2007 องค์กรที่ใช้ pg_trgm สำหรับค้นหาชื่อลูกค้า ชื่อสินค้า หรือที่อยู่ จะได้รับผลกระทบโดยตรง

4. json_strip_nulls() Function Volatility — เปลี่ยนเป็น Immutable

ฟังก์ชัน json_strip_nulls() เดิมถูกกำหนดเป็น Stable แต่ที่จริงแล้วควรเป็น Immutable (ให้ผลลัพธ์เดิมเสมอเมื่อ Input เดิม) การแก้ไขนี้ทำให้สามารถ ใช้ json_strip_nulls() ใน Expression Index ได้ — ช่วยเพิ่มประสิทธิภาพ Query ที่ทำงานกับข้อมูล JSON

5. LATERAL UNION ALL NULL — Query ให้ผลลัพธ์ผิด

เมื่อใช้ LATERAL JOIN ร่วมกับ UNION ALL ที่มีค่า NULL ในบาง Column ระบบจะ ให้ผลลัพธ์ผิดโดยไม่แจ้ง Error — บั๊กประเภทนี้อันตรายมาก เพราะข้อมูลที่ผิดจะถูกใช้ในการตัดสินใจโดยไม่มีใครรู้ตัว

6. NOT NULL Constraint Naming Conflicts

การตั้งชื่อ NOT NULL Constraint อาจ ชนกับ Constraint ที่มีอยู่แล้ว ทำให้ไม่สามารถสร้างตารางหรือเพิ่ม Column ได้ — กระทบ Migration Script และ Schema Change ในระบบ Production

7. pg_stat_get_backend_wait_event() สำหรับ Auxiliary Processes

ฟังก์ชันตรวจสอบ Wait Event ของ Backend Process ให้ข้อมูลผิดสำหรับ Auxiliary Processes เช่น Background Writer, Checkpointer — กระทบการ Monitor ประสิทธิภาพและการวินิจฉัยปัญหา

8. Composite-type Casting ใน PL/pgSQL

การ Cast ข้อมูลแบบ Composite Type ใน PL/pgSQL ทำงานผิดพลาดในบางกรณี — กระทบ Stored Procedure ที่ใช้ Record Type หรือ Row Type ซึ่งเป็นรูปแบบที่พบบ่อยในระบบ ERP ที่มี Business Logic ซับซ้อน

9. hstore Binary Input Crash เมื่อมี Duplicate Keys

Extension hstore จะ Crash เมื่อรับ Binary Input ที่มี Key ซ้ำกัน — กระทบระบบที่ใช้ hstore สำหรับเก็บข้อมูลแบบ Key-Value เช่น Custom Fields หรือ Metadata

สรุปผลกระทบตามระดับความรุนแรง

ระดับ	บั๊ก	ผลกระทบ
วิกฤต	Standby หยุดทำงาน	HA/DR ใช้งานไม่ได้
วิกฤต	pg_trgm crash, hstore crash	ระบบ Crash ทันที
สูง	substring encoding, LATERAL UNION ALL	ข้อมูลผิดแบบเงียบ
ปานกลาง	NOT NULL naming, PL/pgSQL casting	Schema change ล้มเหลว
ต่ำ	json_strip_nulls, wait_event	ประสิทธิภาพ/Monitoring ไม่ถูกต้อง

เวอร์ชันที่ได้รับผลกระทบ

Patch นี้ครอบคลุม ทุก Supported Branch ของ PostgreSQL:

Branch	เวอร์ชันที่มีบั๊ก	เวอร์ชันที่แก้แล้ว
PostgreSQL 18	18.2	18.3
PostgreSQL 17	17.8	17.9
PostgreSQL 16	16.12	16.13
PostgreSQL 15	15.16	15.17
PostgreSQL 14	14.21	14.22

ทำไมเรื่องนี้สำคัญกับองค์กรที่ใช้ Saeree ERP

Saeree ERP ใช้ PostgreSQL เป็นฐานข้อมูลหลักมากว่า 20 ปี ซึ่งหมายความว่า:

• ข้อมูลทางการเงินทั้งหมด — บัญชี สต็อก การจัดซื้อ — อยู่บน PostgreSQL
• Standby Server ที่ใช้สำหรับ DR และ Read Replica อาจหยุดทำงานถ้าไม่ Patch
• รายงานที่ใช้ข้อมูลภาษาไทย อาจแสดงผลผิดจากบั๊ก substring encoding
• Stored Procedure ที่ใช้ PL/pgSQL อาจทำงานผิดพลาดจากบั๊ก Composite-type casting

การ Patch ฐานข้อมูลไม่ใช่เรื่องที่ทำเมื่อ "มีเวลาว่าง" — แต่ต้องทำทันทีที่มี Patch ออกมา โดยเฉพาะ Out-of-cycle Release ที่ออกเพราะปัญหาร้ายแรง

- ทีมงาน Saeree ERP

แนวทางปฏิบัติสำหรับการ Patch ฐานข้อมูลใน Production

สำหรับองค์กรที่ต้องอัปเดต PostgreSQL ในระบบ Production มีขั้นตอนที่ควรปฏิบัติดังนี้:

1. ตรวจสอบเวอร์ชันปัจจุบัน — รัน SELECT version(); บน Server ทุกตัว ทั้ง Primary และ Standby
2. อ่าน Release Notes — ตรวจสอบว่าบั๊กไหนกระทบระบบของคุณ ไม่จำเป็นต้องตกใจทุกบั๊ก แต่ต้อง ประเมินผลกระทบ ก่อน
3. ทดสอบใน Staging — อัปเดต Staging Environment ก่อน รัน Application Test Suite เพื่อยืนยันว่าไม่มีอะไรพัง
4. สำรองข้อมูล — สำรองข้อมูลด้วย pg_dump หรือ pg_basebackup ก่อนอัปเดตทุกครั้ง
5. อัปเดต Standby ก่อน Primary — สำหรับ Minor Release ของ PostgreSQL สามารถอัปเดต Binary แล้ว Restart ได้เลย ไม่ต้องทำ pg_upgrade
6. ตรวจสอบหลังอัปเดต — รัน SELECT version(); อีกครั้ง ตรวจสอบ Replication Lag ของ Standby และทดสอบฟังก์ชันหลักของระบบ

สรุป — สิ่งที่ต้องทำตอนนี้

1. ตรวจสอบเวอร์ชัน PostgreSQL ที่ใช้อยู่ — ถ้าเป็นเวอร์ชันที่มีบั๊ก (18.2, 17.8, 16.12, 15.16, 14.21) ต้องอัปเดตทันที
2. อัปเดตเป็นเวอร์ชันล่าสุด ในแต่ละ Branch (18.3, 17.9, 16.13, 15.17, 14.22)
3. ตรวจสอบ Standby Server — ถ้าใช้ Streaming Replication ให้ตรวจสอบว่ายังทำงานปกติ
4. วางแผนอัปเกรด หากยังใช้ PostgreSQL 13 หรือต่ำกว่า — เพราะหมดอายุการสนับสนุนแล้ว

หากองค์กรของคุณใช้ Saeree ERP และต้องการความช่วยเหลือในการอัปเดต PostgreSQL หรือวางแผน Disaster Recovery สามารถติดต่อทีมที่ปรึกษาเพื่อประเมินความพร้อมของระบบ

แหล่งอ้างอิง

• PostgreSQL 18.3, 17.9, 16.13, 15.17, and 14.22 Released — postgresql.org
• PostgreSQL Release Notes — postgresql.org