PostgreSQL 19, 8-10 özelliği geri çektikten sonra 19 Kasım'a ertelendi; committer'lar yapay zekâ incelemesinin rolünü tartışıyor

PostgreSQL 19 önemli özellikleri kaybetti ve Kasım'a ertelendi

PostgreSQL 19, projenin 15 Ekim'de yayımlanan ilk release candidate duyurusuna göre 19 Kasım 2026'da genel kullanıma sunulacak — bu, The Register'ın 16 Ekim'de orijinal plan olarak aktardığı Eylül sonu ya da Ekim başı penceresinden birkaç hafta sonrasına denk geliyor. Aday duyurusuna göre, yeni bir sorun gecikmeye ya da ikinci bir release candidate yayımlanmasına yol açmadığı sürece bu tarih geçerli kalacak.

Erteleme, alışılmadık ölçüde yoğun bir geri alma dalgasının ardından geldi. Committer Peter Eisentraut, 9 Ekim'de yazdığı yazıda, sayma biçimine bağlı olarak yaklaşık sekiz ila on önemli özelliğin sürümden geri alındığını belirtti. Snowflake'te developer advocate olan Elizabeth Garrett Christensen'in 16 Eylül'de yayımlanan mühendislik yazısı, beta başladığından beri toplam 53 geri alma saydı; kullanıcıya dönük büyükler arasında SQL Property Graph Queries (SQL/PGQ), ALTER TABLE ... MERGE/SPLIT PARTITION(S), UPDATE/DELETE ... FOR PORTION OF, GROUP BY ALL ve online data checksums yer alıyor.

Ayakta kalanlar ve sıradaki adımlar

Eisentraut'a göre PostgreSQL 19'da hâlâ bulunan önemli özellikler arasında REPACK CONCURRENTLY, sequence'ların logical replication'ı ve pg_plan_advice var; RC1 notları ayrıca Beta 4'ten beri parallel autovacuum ve JSON çıktılı COPY (query) TO için yapılan düzeltmeleri listeliyor. Geri alınan özelliklerin çoğunun geri döneceğini, bunun da PostgreSQL 20'yi en erken iniş noktası hâline getirdiğini bekliyor.

The Register, 2023'ten beri SQL standardının parçası olan SQL/PGQ'nun çözümsüz sorunlar nedeniyle çekildiğini ve committer Tom Lane'in Eylül ayında, bunu sürüm 19'da yayımlamanın sürüm sonrası, 20. sürüme kadar düzeltilemeyecek hatalar üreteceğine bahse gireceğini söylediğini aktarıyor.

Yapay zekâ incelemesi açıklaması

Eisentraut'un yazısı bir araç ya da model adı vermiyor; argümanı zamanlama üzerine kurulu. LLM destekli inceleme artık mimari kusurları ve küçük edge case'lerin uzun kuyruğunu, özelliklerin yazıldığı dönemdeki incelemeden daha hızlı yakalıyor — dolayısıyla etkin kalite çıtası kod zaten commit edildikten sonra yükselmiş ve her bulgu sabit bir ele alma maliyeti taşıyor. "Vibe coding"i açıkça dışlıyor; etkilenen kodun bu pratikten önceye dayandığını not ediyor. İkinci bir neden daha veriyor: Kıdemli geliştiricileri kabaca Nisan'dan Ağustos'a kadar beta testi ve inceleme yerine güvenlik düzeltmeleriyle meşgul eden, Vulnpocalypse adını verdiği süreç.

Snowflake yazısı yapay zekâyı sahnenin daha merkezine koydu; yapay zekânın hikâyenin bir parçası olması gerektiğini söyledi ve PostgreSQL'in şu anda resmî bir yapay zekâ katkı politikası olmadığını, ancak yakında bir tanenin beklediğini belirtti.

Birikim karşı açıklaması

Committer Tomas Vondra, 20 Mayıs ile 16 Eylül arasına tarihlenen 12 geri alımın postane listesi tartışmalarını inceledi ve her biri için sorunu yapay zekânın bulup bulmadığını kontrol etti. Özeti: yalnızca dördü muhtemelen ya da kesinlikle yapay zekâ olarak değerlendirilebilir. PostgreSQL danışmanı Christophe Pettus, geri alım başına verilen kararların bu başlıktan daha cimri olduğuna dikkat çekiyor — biri yapay zekâ, biri muhtemelen yapay zekâ, ikisi ise muhtemelen yapay zekâ değil olarak puanlanmış.

Vondra ise suçu geç gelen incelemeye yüklüyor. Geliştirme döngüsü boyunca konusu "Revert" ile başlayan commit'leri çizdiğinde, PG19 geri alımlarının 430. gün civarında, 275. gün civarındaki feature freeze'in oldukça sonra ve genellikle 480. gün civarına denk gelen sürümlerin hemen öncesinde yükseldiğini gördü. Neden olarak güvenlik çalışmalarını gösteriyor: geçen yıl kabaca beş CVE'ye karşı bu yıl şimdiden 44 CVE var ve o, bunu stabilizasyon sırasında inceleme etkinliğinin azalmasının başlıca nedenlerinden biri olarak nitelendiriyor.

Pettus'un kararına göre geri alımlar, yapay zekânın düzeltilemez hatalar bulması vakası değildi. Yapay zekâ süreçte göründü — Vondra, Opus 4.8 ve Opus 5 ile yapılan incelemelerden ve birkaç tartışmada Claude kullanımından söz ediyor — ancak Pettus, committer Noah Misch'in bir modelle incelediği commit'teki dört bulgudan üçünü reddettiğini, oradaki geri alımın Misch'in kendi tasarım yargısından kaynaklandığını yazıyor. Pettus'un çerçevesine göre bulguları süzmek başlı başına inceleme. İki taraf da aynı mekanizmayı tarif ediyor — inceleme geç geldi, sonra projenin sürümden önce düzeltabileceğinden fazlasını buldu — ve bunun ne kadarını bir modelin ürettiğinde anlaşamıyor.

Kullanıcılar ne yapmalı

Projenin beta test rehberi, aday sürümlerin production için olmadığını söylüyor ve Snowflake yazısı şu an için güvenli yükseltme hedefi olarak PostgreSQL 18'i önerdi. RC1 yine de iyi bir test noktası: 19 binary'leriyle verilerinizin bir kopyası üzerinde pg_upgrade --check çalıştırmak, hiçbir şeyi değiştirmeden uyumluluk sorunlarını ortaya çıkarır. GROUP BY ALL, SQL/PGQ ya da partition birleştirme ve bölme komutlarına dayanan yükseltme planları sonraki bir sürüme ertelenmeli.

Neden önemli

Pull request'lerine bir inceleme botu bağlı her ekip için buradaki mekanizma tanıdık gelecektir: bulgu üretmek ucuz, ama her biri yine de onu okuyacak, karar verecek ve cevabın sahibi olacak bir insana ihtiyaç duyar. Aktarılabilir dersler şunlar: pahalı incelemeyi stabilization sırasında değil merge'den önce çalıştırmak ve triage için gerçek kapasite ayırmak. Bu olay ayrıca açık kaynak projeleri, PostgreSQL'in henüz yazmadığı bir politika sorusuyla baş başa bırakıyor — destekli kullanım sorun olmayabilir, ama her karar için bir insan sorumlu kalmalı. Bu arada 19 Kasım tarihi ve eksik özellikler, Postgres üzerine kurulu çok sayıda ürün ve dağıtıma doğru dalgalanıyor.