Multigres Havuzlu Bağlantılarda Postgres Listen/Notify Destekliyor
Multigres, paylaşılan bir dinleyici bağlantısı ve iki katmanlı fan-out ile Postgres'in listen/notify özelliğini bağlantı havuzlamayla uyumlu hale getiriyor.
Postgres'in LISTEN/NOTIFY mekanizması dinleyici sayısı arttıkça ciddi biçimde yavaşlar ve temelde bir oturuma bağlıdır; ancak bir bağlantı havuzlayıcı istemcilere kalıcı bir Postgres oturumu vermediğinden, LISTEN'in tutunacağı bir bağlantı kalmaz. Multigres bu çelişkiyi istemcilerin dinleme oturumuna doğrudan sahip olmasını gerektirmeyerek çözüyor.
Her havuzlayıcı, sorgu havuzundan ayrı, tembel açılan ve kalıcı olarak rezerve edilen tek bir dinleyici bağlantısı tutuyor. Bu bağlantı kanal başına referans sayımıyla yönetiliyor, böylece backend'e kanal başına yalnızca bir LISTEN/UNLISTEN gönderiliyor. NOTIFY ise özel bir işlem gerektirmeden sabit bir hedefe yönlendirilen sıradan bir sorgu gibi çalışıyor, çünkü Postgres bildirimleri sunucu örnekleri arasında geçmiyor. Bildirim Postgres'in kendi çapraz-backend teslim mekanizmasıyla paylaşılan dinleyici bağlantısına ulaştıktan sonra Multigres devreye giriyor: önce gRPC akışıyla havuzlayıcıdan gateway'e, ardından sınırlı kapasiteli bağlantı başına kuyruklarla gateway'den istemciye iki aşamalı bir fan-out gerçekleşiyor.
Tasarım, Postgres semantiğini ince detaylarda da koruyor: yavaş bir istemcinin kuyruğu dolduğunda bildirim engellemek yerine düşürülüp loglanıyor, transaction içindeki LISTEN/UNLISTEN komutları ise commit anına kadar bekletilip net değişim olarak uygulanıyor. Bu yaklaşım, önbellek geçersizleştirme ve iş kuyruğu gibi LISTEN/NOTIFY'a dayanan iş yüklerinin, bağlantı havuzlamasının ölçek avantajından ödün vermeden çalışabilmesini sağlıyor.