PostgreSQL 19, tablo şişkinliğini kilitleme yapmadan geri kazanmayı sağlayan yerleşik REPACK komutunu getiriyor

PostgreSQL 19, VACUUM FULL ve CLUSTER'ı tek bir işlemde birleştiren ve tabloyu tamamen çevrimdışı bırakmadan boşa harcanan disk alanını geri kazandıran bir CONCURRENTLY modu ekleyen yerleşik REPACK komutunu tanıtıyor. Bir dev.to gönderisine göre bu özellik, veritabanı yöneticilerinin yıllardır karşılaştığı bir ikilemi ortadan kaldırıyor: alanı geri kazanmak ile tabloyu erişilebilir tutmak arasında seçim yapmak zorunda kalmak.

REPACK'ın çözdüğü şişkinlik sorunu

Büyük çaplı silme işlemlerinden veya update ağırlıklı iş yüklerinden sonra PostgreSQL tablolarında ölü tuple'lar birikir. Autovacuum bunları temizlerken, dev.to gönderisinde belirtildiği gibi kapladıkları alanı işletim sistemine geri veremez. Şimdiye kadar DBA'ların elinde iki kusurlu seçenek vardı: Tabloyu yeni bir dosyaya yeniden yazan ancak tüm yeniden yazım süresince ACCESS EXCLUSIVE kilidi tutan VACUUM FULL, ya da yalnızca sürümü, izinleri ve bakım penceresi her ortamda uyumluysa çalışan üçüncü taraf pg_repack extension'ı.

CLUSTER aynı yeniden yazımı yapar ama ayrıca satırları bir index'e göre yeniden sıralar; bu da range taramalarına yardımcı olur. Her iki komut temelde aynı işi yapar — canlı tuple'ları yeni bir dosyaya kopyalayıp onunla değiştirmek — aralarındaki tek fark index sırasının korunup korunmamasıdır.

REPACK ne yapıyor

REPACK, eski iki komutu tek bir işlemin modları olarak ele alıyor ve PostgreSQL projesine concurrency gibi ortak özellikleri geliştirebileceği tek bir nokta sunuyor. Canlı satırları kopyalar, her index'i yeni dosyalara yeniden oluşturur ve yeni dosyaları devreye alır.

PostgreSQL 19 Beta 2 itibarıyla komut VERBOSE, ANALYZE ve CONCURRENTLY seçeneklerini destekliyor. Bir tabloda düz REPACK çalıştırmak VACUUM gibi davranırken, USING INDEX eklemek onu CLUSTER gibi davranır. Belirli sütunlar da adlandırılabilir; yazar, bunun geniş bir sütun drop edildikten sonra depolamayı geri kazanmak için yararlı olduğunu belirtiyor. VERBOSE ilerleme çıktısını gösterir, ANALYZE ise yeniden yazımın ardından güncel istatistikleri toplar. Yazar, beta sürecinde resmi kaynak olarak PostgreSQL 19 sürüm notları ve dokümantasyonunun esas alınması gerektiği konusunda uyarıyor.

CONCURRENTLY tabloları nasıl çevrimiçi tutuyor

Öne çıkan özellik REPACK (CONCURRENTLY). Kopyalama sırasında ACCESS EXCLUSIVE kilidi tutmak yerine, tablo kopyalanırken gerçekleşen insert, update ve delete işlemlerini logical decoding ile yakalar, sonra da son dosya takasından hemen önce bunları yeni kopyaya uygular. Exclusive kilidi yalnızca bu son adım için gerekir ve kısa süreliğine tutulur.

Uygulamalı test ne gösterdi

Yazar, birincil anahtara ve iki ikincil index'e sahip bir milyonluk satır tablosu oluşturdu, ardından yoğun veri değişimi simüle etti: her satır iki kez güncellendi, ardından satırların yarısı, sonra üçte biri silindi ve %10'luk bir delete yapıldı. Tablo, bir milyondan az canlı satıra rağmen 241 MB'lık index'lerle birlikte 1341 MB'a büyüdü — toplam 1582 MB.

REPACK (VERBOSE, ANALYZE) yaklaşık 27 saniyede tamamlandı ve kaldırılabilir ile kaldırılamayan satır sürümlerinin yanı sıra CPU, buffer ve WAL istatistiklerini raporladı. İşlem sonrasında tablo 370 MB, index'ler 89 MB ve toplam 459 MB oldu.

İzleme ve sınırlamalar

Yeni bir sistem görünümü olan pg_stat_progress_repack, çalışan bir repack işlemini başka bir oturumdan izlemenizi sağlıyor. Geçerli aşamayı, komutu, relation kimliğini, kullanılan index'i, taranan, eklenen, güncellenen ve silinen heap tuple sayılarını, block ilerlemesini ve index yeniden oluşturma sayısını gösteriyor — böylece bir operatör, işin takılıp takılmadığını tahmin etmek zorunda kalmadan hangi aşamada olduğunu görebiliyor.

Gönderiye göre CONCURRENTLY modunun bazı kısıtlamaları var. Tablo UNLOGGED olduğunda, tablo partition'lı olduğunda (tek tek partition'lar birer birer repack edilebilir olsa da), tablonun birincil anahtarı ve index tabanlı replica kimliği olmadığında veya komut bir transaction bloğu içinde çalıştığında kullanılamaz. Eşzamanlı olsun ya da olmasın her repack, tablo üzerinde MAINTAIN ayrıcalığı gerektirir — bu, düşük ayrıcalıklı migration veya otomasyon kullanıcıları için dikkat edilmesi gereken bir nokta; superuser'ların ise herhangi bir izin değişikliğine ihtiyacı yok.

pg_repack hâlâ gerekiyor mu

Yazara göre evet. PostgreSQL 18 ve öncesinde tek çevrimiçi seçenek olmayı sürdürüyor; sürüm 19'da ise partition başına toplu iş araçları ve çok büyük, uzun süren işlerdeki geçmişi, özellikle tüm partition'lı tablolar için uç durumlarda değerini koruyor. Birincil anahtara sahip, update veya delete kaynaklı veri değişimiyle şişmiş tek bir logged tablo gibi yaygın senaryolarda ise yerleşik REPACK (CONCURRENTLY) hem bir extension bağımlılığını hem de bakım penceresi ihtiyacını ortadan kaldırıyor.

Neden önemli

Tablo şişkinliği her zaman iyi anlaşılmış bir sorundu; eksik olan, alanı geri kazanmak ile tabloyu çevrimiçi tutmak arasında seçim yapmayı dayatmayan bir çözümdü. Çevrimiçi yeniden yazımı özel bir ilerleme görünümüyle çekirdek sunucuya taşıyarak PostgreSQL 19, eskiden planlı bir kesintiye — ya da üçüncü taraf bir extension'a bağımlılığa — dönüşen işi birçok iş yükü için rutin, gözlemlenebilir bir arka plan işlemi haline getiriyor.