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) > > > Thoughts? > > Nik > We were just recording a podcast episode with DBOS founders, and this topic was mentioned – would be great to have these limitations explicitly documented, Nik
