On Tue, Jul 21, 2026 at 10:24:44AM -0700, Nikolay Samokhvalov wrote:
> On Thu, Jul 10, 2025 at 4:50 PM Nikolay Samokhvalov <[email protected]> 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/[email protected]
> - 2013:
> https://www.postgresql.org/message-id/[email protected]
>
> 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 <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
