PostgreSQL 19 sürümü yapay zekâ hata raporları nedeniyle gecikti

Robert Haas'ın 30 Ekim 2026 Cuma günü yayımlanan blog yazısına göre PostgreSQL 19, projenin genellikle Eylül ortası ile Ekim ortası arasındaki olağan pencere yerine muhtemelen Kasım'da yayımlanacak. Gecikme, beta döneminin sonlarında birkaç büyük özelliğin geri alınmasının ve büyük dil modelleriyle bulunan hata raporlarındaki artışın ardından geldi.

Yayın zamanlaması ve geç dönem geri almalar

Son on yılda PostgreSQL ana sürümlerinin zamanlaması öngörülebilir oldu; sürümler Eylül ortasından önce ve Ekim ortasından sonra gelmedi. Bu yıl PostgreSQL 19 büyük olasılıkla Kasım'a kadar yayımlanmayacak ve proje bunu daha da erteleyebilir. 27 Ağustos ile 15 Eylül arasında UPDATE/DELETE FOR PORTION OF, SQL Property Graph Queries (SQL/PGQ) ve ALTER TABLE ... MERGE PARTITION/SPLIT PARTITION dahil birkaç oldukça büyük özellik geri alındı. Özellik dondurmasından hemen sonra ana özellik geri almaları özellikle nadir değildir; bu dondurma her yıl 8 Nisan'da gerçekleşir, ancak birden fazla ana özelliğin bu kadar geç bir tarihte çekilmesi olağandışıdır.

LLM hata raporları iş yükünü artırıyor

Robert Haas değişikliği LLM'lere bağlıyor. 8 Nisan 2025 ile 25 Eylül 2025 arasında PostgreSQL'in master dalına 1,037 commit ve REL_18_STABLE dalına 724 commit yapıldı. 2026'da aynı tarih aralığında master dalına 1,443 commit ve REL_19_STABLE dalına 1,169 commit yapıldı. Özellik dondurması ile 25 Eylül arasındaki master dalı commitleri geçen yıla göre hafifçe azaldı, geri yamalanan commitler ise yüzde 60'tan fazla arttı. 2025'te REL_17_STABLE dalına 248 commit, 2026'da REL_18_STABLE dalına 433 commit yapıldı; yani en az bir önceki sürüme geri yamalanan commitler tek bir yılda yüzde 74'ten fazla arttı. İnternet'te çok sayıda insan artık LLM kullanarak bulduğu PostgreSQL hatalarını bildiriyor ve committer'lar bunları düzeltmek için oldukça meşgul.

Kalite, inceleme süresi ve uzun vadeli sorular

İki etken devreye giriyor. Birincisi, çok daha fazla hata bulunduğu için düzeltmeler daha fazla zaman alıyor ve LLM'lerce taslak haline getirilen düzeltmeler her zaman doğru veya PostgreSQL standartlarına uygun olmuyor, bu nedenle insanlar tarafından incelenip onaylanmaları gerekiyor. İkincisi, sürüm değişikliklerini incelemek için harcanacak zaman güvenlik sorunlarına ve geri dallardaki diğer hatalara ayrıldı, bu yüzden 19. sürüm gönderilmeden önce neyin geri alınması gerektiğini belirlemek daha uzun sürdü. Haas gecikmenin özellikle endişe verici olmadığını ve doğrudan projenin kaliteye verdiği önemden kaynaklandığını söylüyor. Uzun vadeli tablo daha az net: insanlar tarafından bulunamayan ama LLM'lerin bulabildiği kırk yıllık hatalarla PostgreSQL'in nasıl yetişeceğini ve yenilik yapmaya devam edeceğini bilmiyor. Kod tabanına yüksek değer biçiyor, mükemmel olmadığını söylüyor ve her özelliğin yapay zekâ tarafından incelendiği bir ortamda LLM'lerin geliştiricileri seviyelerini yükseltmeye zorlayacağını savunuyor.

Kaynaklar: Lobsters