Robert Haas, một committer cốt lõi của PostgreSQL, ngày 30/10 đã đăng một bài blog giải thích vì sao bản phát hành lớn năm nay bị muộn. Suốt mười năm qua, các phiên bản chính của PostgreSQL đều ra mắt trong khoảng giữa tháng 9 đến giữa tháng 10, còn PostgreSQL 19 nhiều khả năng phải đến tháng 11, và dự án cũng có thể lùi thêm nữa. Lý do ông đưa ra chỉ gói trong một câu:
"The short answer is that LLMs happened." (Nói ngắn gọn, là LLM đã xuất hiện.)
Haas hiện là kỹ sư phần mềm cao cấp tại Databricks. Bài viết là nhận định cá nhân của ông, và ông cũng không đưa ra ngày phát hành mới.
Ba tính năng lớn bị rút lại trong tháng cuối
Mỗi năm, thời điểm đóng băng tính năng là ngày 8/4, và việc rút tính năng sau đó vốn không hiếm. Điểm khác của năm nay nằm ở thời điểm và khối lượng: từ 27/8 đến 15/9, ba tính năng lớn lần lượt bị hoàn tác.
UPDATE/DELETE FOR PORTION OF- Truy vấn đồ thị thuộc tính SQL (SQL/PGQ)
ALTER TABLE ... MERGE PARTITION / SPLIT PARTITION
Theo Haas, những năm trước cũng có tính năng bị rút, nhưng hiếm khi nhiều tính năng lớn bị gỡ cùng lúc ở thời điểm muộn như vậy.
Số commit tăng sáu phần mười, còn các committer không hề cẩu thả hơn
Ông cố định khung thống kê từ 8/4 đến 25/9 mỗi năm để so sánh lượng bản sửa lỗi giữa hai năm. Năm ngoái, số commit vào REL_18_STABLE là 724; năm nay, số commit vào REL_19_STABLE là 1169, tăng hơn 60%. Với nhánh ổn định liền trước, REL_17_STABLE năm ngoái có 248 commit, còn REL_18_STABLE năm nay có 433, tăng hơn 74%.
Haas không cho rằng lượng commit tăng thêm này là do mọi người viết code tệ đi. Ông đánh giá mức độ cẩn trọng của các committer gần như năm trước, và thay đổi nằm ở khâu phát hiện: nhiều người bắt đầu dùng LLM để săn lỗi PostgreSQL rồi báo thẳng lên.
"What's different now is that it's become vastly easier to find those bugs." (Điểm khác bây giờ là việc tìm ra những lỗi đó đã dễ hơn rất nhiều.)
Cách quy kết này có một khoảng trống: lịch sử commit không ghi lỗi do ai phát hiện và bằng công cụ nào, còn bài viết cũng không nêu tỷ lệ báo cáo từ LLM trong tổng số. Mức tăng nói trên là số liệu đo được, còn nhận định "chủ yếu do LLM" là quan sát của một committer lâu năm.
Điểm nghẽn là khâu rà soát thủ công
Cơ chế gây chậm trễ có hai tầng. Tầng thứ nhất: lỗi nhiều thì việc sửa tự nhiên tốn thời gian hơn. LLM có thể soạn bản vá, nhưng bản vá chưa chắc đúng, cũng chưa chắc phù hợp quy chuẩn của dự án, và cuối cùng vẫn phải do committer xem xét từng cái rồi mới hợp nhất. Tầng thứ hai kín đáo hơn: thời gian lẽ ra dành để rà soát nội dung của phiên bản mới lại bị các vấn đề bảo mật và lỗi ở nhánh cũ chiếm mất, nên việc quyết định tính năng nào cần rút cũng bị trì hoãn theo.
Có thể đặt chuyện này cạnh thí nghiệm Firefox của Epoch AI vài ngày trước. Epoch đo phía tấn công: dùng GLM 5.3 để viết mã khai thác ngay trong khoảng thời gian sau khi bản vá được công bố, với chi phí tính toán khoảng 1000 USD cho mỗi phiên bản. Haas nói về phía bảo trì: cùng một năng lực áp vào dự án đã hàng chục năm tuổi thì số báo cáo tăng trước, còn số người đủ khả năng rà soát code không tăng theo. Biến số chung của hai phía là chi phí phát hiện lỗ hổng, và nó giảm nhanh hơn chi phí sửa lỗi.
Chuyện này cũng không xa với các nhóm kỹ thuật ở Trung Quốc. Không ít sản phẩm cơ sở dữ liệu đám mây phát triển tiếp trên nền PostgreSQL; khi lượng commit backport ở thượng nguồn tăng sáu đến bảy phần mười, khối lượng công việc theo kịp bản vá ở hạ nguồn cũng có thể tăng tương ứng. Mức ảnh hưởng cụ thể đến đâu thì hiện chưa nhà cung cấp nào công bố con số.
Kho lỗi tồn đọng bốn mươi năm mới là áp lực dài hạn
Bản thân việc trễ hẹn này không làm Haas lo lắng. Ông nói nhìn trong chu kỳ dài thì chưa phải lâu, và nó xuất phát từ sự kiên định của dự án với chất lượng. Ông cũng nhấn mạnh rằng việc AI tìm ra các vấn đề này không làm thay đổi đánh giá của ông về chất lượng của codebase.
Điều khiến ông thiếu chắc chắn là phần phía sau. Dự án đã tích lũy khoảng bốn mươi năm lỗi mà con người chưa phát hiện, LLM có thể đào ra khá nhiều, và nguyên văn lời ông là "how are we ever going to catch up". Từ nay, mỗi tính năng mới đều sẽ bị AI rà một lượt, điều này vừa là áp lực, vừa có thể khiến code vững chắc hơn. Ông chưa đưa ra giải pháp, chỉ nói bản thân và nhiều người khác đang tìm cách.
PostgreSQL 19 rốt cuộc sẽ ra mắt vào ngày nào còn phải chờ thông báo tiếp theo của nhóm phát hành.
Nguồn tham khảo: blog cá nhân của Robert Haas; CocoLoop; báo cáo thí nghiệm công khai của Epoch AI; số liệu commit theo nhánh lấy theo cách tính trong bài của Haas, chưa được tính lại riêng.