Re: docs: LISTEN/NOTIFY performance considerations

On Tue, Jul 21, 2026 at 10:24:44AM -0700, Nikolay Samokhvalov wrote:
> On Thu, Jul 10, 2025 at 4:50 PM Nikolay Samokhvalov <nik(at)postgres(dot)ai> wrote:
>
> Greetings!
>
> LISTEN/NOTIFY has known performance issues that aren't documented but
> regularly surprise users in production – my customers and I encountered
> some of them multiple times.
>
> They were also discussed in the past, e.g.,:
> - 2008: https://www.postgresql.org/message-id/5215.1204048454@sss.pgh.pa.us
> - 2013: https://www.postgresql.org/message-id/3598.1363354686@sss.pgh.pa.us
>
> Recently, Recall.ai had production outages from hitting these exact issues:
> https://www.recall.ai/blog/postgres-listen-notify-does-not-scale (popped up
> to no.1 position on HN right now: https://news.ycombinator.com/item?id=
> 44490510).
>
> It's probably a good time to consider improving this area, but while it's
> not happening, I propose documenting the risks to help users avoid
> incidents (backpatching to all supported versions).
>
> The proposed docs patch to the LISTEN/NOTIFY docs includes words about:
> 1. Global lock during commit affecting all databases in cluster
> 2. O(N²) duplicate checking performance
> 3. How to diagnose (log_lock_waits example)
> 4. Alternatives (logical decoding)
>
> We were just recording a podcast episode with DBOS founders, and this topic was
> mentioned – would be great to have these limitations explicitly documented,

We have a LISTEN/NOTIFY improvement in PG 19:

https://www.postgresql.org/docs/19/release-19.html#RELEASE-19-PERFORMANCE

Improve NOTIFY to only wake up backends that are listening to specified
notifications (Joel Jacobson) §

Previously most backends were woken by NOTIFY.

I think the big issue is if we document this, will we remember to keep
it current? Would a wiki page be better?

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

Do not let urgent matters crowd out time for investment in the future.