PostgreSQL 19 và làn sóng revert: Khi LLM review nâng chuẩn chất lượng và lộ ra điểm yếu của quy trình

PostgreSQL 19 đang chứng kiến một hiện tượng hiếm gặp: khoảng 8 đến 10 tính năng quan trọng bị revert ngay trong giai đoạn beta, một số khá muộn. Peter Eisentraut, người trực tiếp là developer và committer của một số tính năng trong đó, đã chia sẻ góc nhìn thẳng thắn về nguyên nhân và bài học rút ra.

Chuyện gì đã xảy ra?

Việc revert một vài tính năng trong mỗi chu kỳ phát triển là chuyện bình thường, thường chỉ khoảng một tính năng. Nhưng lần này con số cao bất thường, và nhiều lần revert diễn ra rất muộn so với lịch beta.

Tác giả không né tránh khả năng đầu tiên: có thể chính chất lượng code chưa đủ tốt. Ông thừa nhận điều này có phần đúng và nhấn mạnh rằng cần nói ra để tránh tạo cảm giác mọi vấn đề đều do yếu tố khách quan. Bên cạnh đó cũng có thể chỉ là sự trùng hợp — cộng đồng đã có một chuỗi thành công dài và vô tình chọn những tính năng quá khó để hoàn thành đúng hạn.

LLM review: chuẩn chất lượng bị nâng lên giữa chừng

Đây có lẽ là điểm đáng chú ý nhất. Một số tính năng bị revert có lỗi kiến trúc nghiêm trọng, khó sửa nhanh trong beta. Nhưng phần lớn lại là những lỗi nhỏ liên quan đến các edge case — loại lỗi mà trước đây phải mất nhiều năm mới lộ dần và được vá từng chút một.

Với sự hỗ trợ của LLM-assisted code review, những lỗi này được phát hiện nhanh hơn nhiều. Hệ quả là developer đột nhiên đối mặt với danh sách khoảng bốn mươi báo cáo lỗi. Dù trung bình mỗi lỗi chỉ cần sửa ba dòng, chi phí cố định cho việc xử lý từng báo cáo vẫn rất lớn — và thời gian thì hết.

Phần lớn các tính năng bị revert đều được viết từ lâu, khi LLM-assisted code review chưa hữu ích như hiện nay. Nghĩa là chuẩn chất lượng hiệu dụng đã được nâng lên sau thời điểm tính năng được viết và commit.

Tác giả cũng lưu ý rằng, theo những gì ông quan sát được, tình trạng này không phải do "vibe coding". Toàn bộ code liên quan được viết từ rất lâu trước khi khái niệm đó ra đời.

Khủng hoảng bảo mật làm giảm nguồn lực review

Một yếu tố quan trọng khác là cái mà cộng đồng gọi là "Vulnpocalypse". Từ khoảng tháng 4 — thời điểm bắt đầu feature freeze của PostgreSQL 19 và cũng là lúc khủng hoảng bảo mật khởi phát — đến tháng 8 (bản phát hành bảo mật gần nhất), nhiều senior developer bị cuốn vào việc vá lỗ hổng.

Kết quả là hoạt động review và kiểm thử bổ sung vốn diễn ra trong giai đoạn beta bị sụt giảm, rồi mới phục hồi vào tháng 8. Điều này giải thích vì sao rất nhiều vấn đề mới chỉ được phát hiện muộn và vì sao các đợt revert dồn dập đến vậy.

Về lựa chọn giữa trì hoãn phát hành để sửa thêm và giữ nguyên lịch, cộng đồng nghiêng về phương án thứ hai. Tác giả thừa nhận nếu có thêm khoảng hai tháng, nhiều lỗi nhỏ có thể đã được xử lý — nhưng cũng khó đoán định được "đuôi dài" của vấn đề dài đến đâu.

Độ phức tạp: "mọi thứ hoạt động với mọi thứ"

PostgreSQL nổi tiếng với triết lý "everything works with everything" — mọi tính năng đều phải tương thích với mọi tính năng khác. Đây chính là sức hấp dẫn của hệ quản trị này, nhưng nó cũng đặt gánh nặng khổng lồ lên quá trình phát triển.

Tác giả đưa ra một ví dụ trừu tượng: giả sử thêm một tính năng ở tầng ngôn ngữ truy vấn SQL. Nó có hoạt động với domain không? Với domain trên kiểu composite thì sao? Khi một trường cũng là domain? Khi domain có ràng buộc not null? Khi một cột bị xóa rồi thêm lại? Khi đó là phần của một table partition đã detach và reattach với thứ tự cột khác? Khi nó nằm trong một view được gọi từ security-definer function từ một trigger?

Không ai có thể kiểm thử thủ công hoặc thậm chí liệt kê hết các trường hợp này. Nhưng LLM-assisted fuzzing có thể tìm ra vấn đề rất nhanh. Đây được xem là hướng đi tất yếu cho phát triển tính năng trong tương lai.

Song song đó, cộng đồng cũng cần làm cho các internal interface trở nên vững chắc hơn, để mỗi tổ hợp ngữ cảnh mới không mở ra quá nhiều khả năng tương tác tiềm ẩn.

Hướng tới tính năng "experimental"

Một ý tưởng đã được cộng đồng PostgreSQL cân nhắc từ lâu: commit tính năng với trạng thái "experimental" rồi hoàn thiện dần trong main tree. Cơ chế này sẽ hữu ích cho ít nhất một số tính năng bị revert lần này, nhưng cách triển khai cụ thể vẫn chưa được thống nhất. Tác giả xem đây là điểm cần làm rõ ràng và cụ thể trong thời gian tới.

PostgreSQL 19 vẫn là bản phát hành đáng chờ đợi

Bất chấp làn sóng revert, tác giả khẳng định bản phát hành này vẫn rất hấp dẫn. Một số điểm nhấn đáng chú ý:

• REPACK CONCURRENTLY
• Logical replication của sequence — bản thân đây cũng là tính năng từng bị revert trước đó
• Planner hinting với pg_plan_advice

Và sau tất cả những lần rà soát bổ sung, PostgreSQL 19 hứa hẹn sẽ đặc biệt vững chắc.

Về tương lai, tác giả thừa nhận rất khó dự đoán. Vài tháng trước ông từng nói PostgreSQL 20 có thể không có tính năng mới nào ngoài sửa lỗi. Thực tế mọi thứ diễn ra nhanh hơn: PostgreSQL 19 hiện có khoảng một nửa số tính năng lớn so với kỳ vọng ban đầu, trong khi PostgreSQL 20 đã có sẵn vài tính năng tốt đạt mức 80% — chỉ còn chờ 20% cuối cùng.

Cảm ơn tất cả những ai đã lên tiếng động viên, trực tiếp hoặc qua mạng. Đó là điều quan trọng nhất. Tôi tin nhiều tính năng bị revert sẽ sớm quay trở lại.

Góc nhìn cho cộng đồng phát triển tại Việt Nam

Câu chuyện của PostgreSQL 19 mang lại bài học thực tế cho các đội phát triển phần mềm trong nước, đặc biệt là những nhóm đang áp dụng AI vào quy trình review code.

Thứ nhất, công cụ review bằng LLM giúp phát hiện lỗi nhanh hơn, nhưng cũng nâng cao chuẩn chất lượng một cách đột ngột. Những dự án legacy viết cách đây vài năm có thể bất ngờ bị "soi" ra hàng loạt vấn đề mà trước kia không ai để ý — và điều này cần được tính đến khi lập kế hoạch phát hành.

Thứ hai, chi phí cố định của việc xử lý từng báo cáo lỗi không thể bỏ qua. Một lỗi sửa ba dòng vẫn tốn thời gian đọc hiểu, tái hiện, kiểm thử và review. Khi số lượng báo cáo tăng vọt, đội ngũ cần có chiến lược phân loại ưu tiên thay vì xử lý tuần tự.

Thứ ba, các giai đoạn khủng hoảng chiếm dụng nhân sự chủ chốt sẽ để lại hệ quả dây chuyền. Với các công ty công nghệ Việt Nam đang vận hành hệ thống lớn, việc đảm bảo có phương án dự phòng nhân sự review trong các đợt xử lý sự cố bảo mật là điều nên chuẩn bị trước, chứ không phải ứng biến khi sự cố xảy ra.