Multigres Brings Listen/Notify to Pooled Postgres Connections

Postgres's LISTEN/NOTIFY mechanism slows dramatically as listener count grows and is fundamentally tied to a session — but a connection pooler never gives clients a durable session, leaving LISTEN nothing to attach to. Multigres resolves this by never letting clients own a listening session directly.

Each pooler instead keeps a single, lazily-opened, permanently reserved listener connection separate from the query pool, tracking channels via refcounting so exactly one LISTEN/UNLISTEN reaches the backend per distinct channel. NOTIFY needs no special handling at all — it's routed as an ordinary query to a fixed target, since a Postgres notification never crosses instances. Once Postgres's native cross-backend delivery lands the notification on that shared listener connection, Multigres takes over with a two-level fan-out: a gRPC stream from pooler to gateway, then bounded per-connection queues from gateway to client.

The design also preserves Postgres semantics in the edge cases: a slow client's full queue gets notifications dropped and logged rather than blocking everyone else, and LISTEN/UNLISTEN issued inside a transaction is buffered and applied as a net change only at commit. Together these details let workloads relying on LISTEN/NOTIFY — cache invalidation, job queues — run safely on pooled connections without sacrificing the scalability pooling provides.