Committer inti PostgreSQL, Robert Haas, menulis di blognya pada 30 Oktober untuk menjelaskan mengapa rilis mayor tahun ini terlambat. Selama sepuluh tahun terakhir, versi mayor PostgreSQL selalu dirilis antara pertengahan September dan pertengahan Oktober, tetapi PostgreSQL 19 besar kemungkinan baru rilis pada November, dan pihak proyek bisa saja menundanya lebih jauh. Alasan yang ia berikan hanya satu kalimat:
"The short answer is that LLMs happened." (Singkatnya, LLM sudah hadir.)
Haas kini menjabat senior principal software engineer di Databricks. Tulisan ini merupakan penilaian pribadinya, dan ia tidak menyebut tanggal rilis baru.
Tiga fitur besar ditarik pada bulan terakhir
Feature freeze jatuh pada 8 April setiap tahun, dan menarik fitur setelah freeze bukan hal aneh. Yang berbeda tahun ini adalah waktu dan bobotnya: antara 27 Agustus dan 15 September, tiga fitur besar di-revert satu per satu.
UPDATE/DELETE FOR PORTION OF- kueri grafik properti SQL (SQL/PGQ)
ALTER TABLE ... MERGE PARTITION / SPLIT PARTITION
Menurut Haas, penarikan fitur juga terjadi di tahun-tahun lain, tetapi jarang sekali sepenting dan sebanyak ini pada waktu yang selarut ini.
Commit naik enam puluh persen, committer tidak jadi ceroboh
Ia menetapkan jendela hitung pada 8 April sampai 25 September setiap tahun, lalu membandingkan jumlah perbaikan di dua tahun. Tahun lalu commit yang masuk ke REL_18_STABLE berjumlah 724, tahun ini yang masuk ke REL_19_STABLE berjumlah 1.169, naik lebih dari 60%. Untuk cabang stabil sebelumnya, REL_17_STABLE tahun lalu menerima 248 commit, sedangkan REL_18_STABLE tahun ini 433, naik lebih dari 74%.
Haas tidak menganggap kenaikan commit itu berarti kualitas kode memburuk. Ia menilai tingkat kehati-hatian committer kurang lebih sama seperti tahun-tahun sebelumnya; yang berubah ada di tahap penemuan: banyak orang kini memakai LLM untuk mencari bug di PostgreSQL, lalu langsung melaporkannya.
"What's different now is that it's become vastly easier to find those bugs." (Yang berbeda sekarang, menemukan bug-bug itu jauh lebih mudah.)
Atribusi ini punya celah: riwayat commit tidak mencatat siapa yang menemukan bug dan dengan alat apa, dan tulisan itu juga tidak menyebut berapa persen laporan yang berasal dari LLM. Angka kenaikan di atas adalah hasil pengukuran, sedangkan "terutama karena LLM" adalah pengamatan seorang committer senior.
Yang tersendat adalah peninjauan oleh manusia
Keterlambatan ini bekerja di dua lapis. Lapis pertama, bug yang lebih banyak membuat perbaikan memakan waktu lebih lama. LLM bisa menyusun draf patch, tetapi patch itu belum tentu benar dan belum tentu sesuai kaidah proyek, sehingga committer tetap harus meninjaunya satu per satu sebelum menggabungkannya. Lapis kedua lebih tersembunyi: waktu yang seharusnya dipakai meninjau isi versi baru tersita oleh masalah keamanan dan cacat di cabang lama, sehingga keputusan fitur mana yang harus ditarik pun ikut tertunda.
Hal ini bisa dibaca bersama eksperimen Firefox dari Epoch AI beberapa hari lalu. Epoch mengukur sisi serangan: memakai GLM 5.3 untuk menulis exploit dalam jeda setelah patch dipublikasikan, dengan biaya komputasi sekitar 1.000 dolar AS per versi. Haas berbicara dari sisi pemeliharaan: kemampuan yang sama diarahkan ke proyek berusia puluhan tahun, jumlah laporan naik lebih dulu, sementara jumlah orang yang mampu meninjau kode tidak ikut naik. Variabel yang sama di kedua sisi adalah biaya menemukan kerentanan, yang turun lebih cepat daripada biaya memperbaikinya.
Ini bukan hal yang jauh bagi tim di Tiongkok. Banyak produk basis data cloud dikembangkan lebih lanjut dari PostgreSQL, sehingga jika volume yang digabung ke hulu naik 60% sampai 70%, beban kerja hilir untuk mengikuti patch juga bisa membesar. Seberapa besar dampaknya, belum ada vendor yang memberikan angkanya.
Tumpukan empat puluh tahun adalah tekanan jangka panjang
Haas tidak terlalu cemas soal keterlambatan ini. Ia mengatakan dalam rentang panjang ini bukan penundaan yang lama, dan hal itu lahir dari keteguhan proyek menjaga kualitas. Ia juga menegaskan bahwa temuan AI atas masalah-masalah ini tidak mengubah penilaiannya terhadap kualitas basis kode.
Yang membuatnya tidak yakin adalah apa yang ada di depan. Proyek ini mengumpulkan sekitar empat puluh tahun bug yang tidak ditemukan manusia, dan LLM bisa menggali cukup banyak di antaranya; kata-katanya sendiri, "how are we ever going to catch up" (bagaimana kita bisa mengejar). Ke depan, setiap fitur baru akan ditinjau oleh AI, yang menjadi tekanan sekaligus bisa membuat kode lebih kokoh. Ia tidak menawarkan solusi, hanya mengatakan dirinya dan banyak orang lain sedang mencari jalan keluar.
Kapan tepatnya PostgreSQL 19 rilis akan bergantung pada pengumuman tim rilis berikutnya.
Sumber: blog pribadi Robert Haas; CocoLoop; laporan eksperimen publik Epoch AI; statistik commit per cabang mengikuti cara hitung yang diberikan dalam tulisan Haas dan tidak dihitung ulang secara terpisah.