PostgreSQL 19 Ekim'e sarkıyor: SQL/PGQ, GROUP BY ALL ve partition merge düşürüldü

PostgreSQL 19, alışılmış Eylül sonu sürüm penceresini kaçırdı. Proje, 24 Eylül 2026'da Beta 4'ü yayınladı ve duyurusunda artık Ekim başında bir release candidate'e, genel kullanıma sunulmanın da aynı ayın ilerleyen günlerinde olabileceğine işaret ediliyor. dev.to'daki döngü özetine göre gecikme bilinçli bir taviz: topluluk, hazır olmayan özellikleri çıkardı ki sürüm güvenilir kalsın.

Sürüm şu anda nerede

PostgreSQL'ün büyük sürümleri normalde her sonbahar, Eylül'ün sonlarında gelir. dev.to'da özetlendiği gibi Beta 4 duyurusu Ekim başı için bir release candidate planlıyor ve GA'nın da Ekim'de olabileceğini söylüyor; belirtilen gerekçe ise bakımcıların bazı özellikleri yarım teslim etmektense sürümden çıkarmayı tercih etmesi.

Snowflake'in Beta 4'ten yaklaşık bir hafta önce yayınladığı mühendislik yazısı, beta programının başlangıcından bu yana 53 geri alma (revert) sayıyor; bu sayı tüm PostgreSQL 18 döngüsündeki yaklaşık 44 geri almayla kıyaslanıyor. Snowflake'e göre bu yılı alışılmadık yapan şey sayı değil zamanlama: birçok geri alma geç geldi ve birkaçı, hata avlamak ve yeniden üretilebilir test durumları oluşturmak için yapay zekâ araçları kullanılarak yapılan incelemelerden sonra, çoğu zaman öne çıkan özellikleri vurdu.

Neler çıkarıldı

Beta 4 duyurusu Beta 3'ten bu yana yapılan değişiklikleri listeliyor: SQL/PGQ property graph sorguları, veri checksum'larının çevrimiçi etkinleştirilip devre dışı bırakılması, temporal UPDATE/DELETE ... FOR PORTION OF sözdizimi, ALTER TABLE ... MERGE PARTITIONS ve SPLIT PARTITIONS ile yeni pg_get_role_ddl(), pg_get_tablespace_ddl() ve pg_get_database_ddl() fonksiyonlarının tümü çıkarıldı.

Döngünün daha erken dönemlerinde Snowflake'in yazısı ek geri almalar kaydediyor: ORDER BY girdileri varsayılan olmayan eşitlik semantiği kullandığında yanlış sonuçlar döndürebileceği commit sonrası bir incelemede ortaya çıkan GROUP BY ALL bunlara dahil. Ayrıca pg_dumpall için metin olmayan çıktı formatları, sütunlara kaskadlanan JSON_TABLE ON ERROR işleme davranışı, nonvolatile kısıtlamalara sahip domain'ler için fast defaults, veritabanına özgü mantıksal replikasyon anlık görüntüleri ve pg_stat_statements içindeki iç içe sorgu takibi de kaldırıldı. Snowflake, property graph'ların, GROUP BY ALL'ın ve partition merge/split'in PostgreSQL 20 çalışması olarak geri döneceğini öngörüyor.

lz4 sorusu

Bir konu gerçekten çözümsüz kaldı. Snowflake, varsayılan TOAST sıkıştırma yönteminin pglz'den lz4'e geçirilmesinin eksik buildfarm kapsamı nedeniyle geri alındığını bildiriyor; ancak 14 Eylül tarihli resmi sürüm notları değişikliği hâlâ listeliyor. dev.to makalesi, iki kaynağı çelişkili olarak ele alıp GA'daki nihai notları kontrol etmeyi öneriyor; bu arada default_toast_compression ayarı açıkça yapılandırılabilir.

Ayakta kalanlar

Mevcut sürüm notlarında hâlâ şunlar var: disk alanını geri kazanan ve VACUUM FULL ile CLUSTER'ı birleştirerek bir tabloyu yeniden düzenleyen, eşzamanlı bir seçenek de sunan REPACK; sorgu planlayıcısı kararlarını dengelemek için yeni bir extension olan pg_plan_advice; ve autovacuum_max_parallel_workers ile tablo başına autovacuum_parallel_workers ayarıyla kontrol edilen paralel autovacuum. SQL tarafında ise INSERT ... ON CONFLICT DO SELECT ... RETURNING artık çakışan satırları döndürebiliyor ve lead(), lag(), first_value(), last_value() ile nth_value() için IGNORE NULLS / RESPECT NULLS desteği eklendi.

Snowflake, REPACK'i, fast-path foreign key kontrollerini ve postgres_fdw istatistik içe aktarımını riskli olarak işaretlemişti. Beta 4 sonrasında hem REPACK hem de foreign key kontrol performansı çalışması için düzeltmeler geldi; dev.to makalesi bunu ikisinin hâlâ sürümde olduğuna işaret olarak yorumluyor, ancak GA'ya kadar hiçbir şey kesin değil.

Neden sarktı

Snowflake bu kargaşanın büyük kısmını yapay zekâ destekli incelemeye bağlıyor: daha fazla katkımcı hataları ortaya çıkarmak ve yeniden üretilebilir durumlar üretmek için yapay zekâ araçları kullanıyor ve ortaya çıkan düzeltmeler, özellikleri yerinde yamalamaktansa sonraki bir sürüme ertelemeyi daha mantıklı kılacak kadar büyüktü. Şirket, güvenlik çalışmasıyla bir benzerlik kuruyor; PostgreSQL'ün bir zamanlar sürüm başına ortalama birkaç CVE ile geldiğini, Ağustos 2026'daki PostgreSQL 18 yamasının ise 28 CVE taşıdığını not ediyor. Snowflake ayrıca, yazım anında projenin yapay zekâ katkılarına dair resmî bir politikasının olmadığını da gözlemliyor.

dev.to makalesinin hükmü, sürecin tasarlandığı gibi çalıştığı yönünde: hazır olmayan özellikler çıkarıldı ve gerekçeler projenin hackers e-posta listesinde herkese açık.

GA'dan önce ne yapmalı

Snowflake, bugün güvenilir üretim yükseltme hedefi olarak PostgreSQL 18'i gösteriyor ve dev.to makalesi de 19 final olana kadar orada kalınmasını öneriyor. Pratik kontrol listesi şu şekilde: kaldırılan sözdizimi — GROUP BY ALL, GRAPH_TABLE, FOR PORTION OF ve MERGE/SPLIT PARTITIONS gibi — için migration'ları, ORM tarafından üretilen SQL'i ve dahili araçları grep'leyin; ve gerçekten kullanmayı düşündüğünüz özellikleri, özellikle REPACK ve foreign key değişikliklerini, beta üzerinde gerçek iş yükleriyle test edin.

Neden önemli

Takvim kaymasının kendisi birkaç haftalık bir mesele; ancak geri almalar, 19'da graph sorgularını veya partition birleştirmeyi planına dahil eden herkesin yükseltme planlarını yeniden yazıyor: bu çalışma artık bir sonraki büyük sürümü bekliyor. Bu döngü ayrıca yapay zekâ destekli incelemenin sürüm dinamiklerini nasıl değiştirdiğini gösteriyor; daha yoğun denetim daha fazla kusur, daha geç geri almalar ve daha büyük güvenlik paketleri ortaya çıkarıyor. Ve lz4 varsayılanına dair anlaşmazlık, GA sürüm notları gelene kadar belgelenmiş özelliklerin bile geçici sayılması gerektiğinin bir hatırlatıcısı.