JoelJacobson

Recently there was an HN thread: "Postgres LISTEN/NOTIFY does not scale", https://news.ycombinator.com/item?id=44490510

We're now working on improving the scalability of LISTEN/NOTIFY in PostgreSQL, and to guide that work, I'd like to better understand how it's used (or was used) in real-world systems. What works well? What doesn't?

The current implementation has some known scalability bottlenecks:

1. Thundering Herd Problem: A NOTIFY wakes up all listening backends in the current database, even those not listening on the notified channel. This is inefficient when many listeners are each listening to their own channels (e.g. in job queues).

2. Commit Lock Contention: NOTIFY operations are serialized behind a heavyweight lock at transaction commit. This can become a bottleneck when many transactions send notifications in parallel.

If you've used LISTEN/NOTIFY in production, I'd love to hear:

- What is/was your use case?

- Does each client listen on its own channel, or do they share channels?

- How many listening backend processes?

- How many NOTIFYs in parallel?

- Are you sending payloads? If so, how large?

- What worked well for you? What didn't?

- Did you hit any scalability limits?

Feedback much appreciated, thanks!

/Joel

End-to-end encryption is pointless if you can be tricked into screen sharing. I’d like to see OS-level APIs let app developers set a "no screen sharing" flag that automatically blanks/obscures the app's contents during screen capture or remote control. This would be per-app and cannot be disabled by users—so secure messaging apps (e.g., Signal) could opt in, preventing accidental leaks via screen sharing.

Questions for HN:

    - What problems do you see with the approach?
    - Any better approaches?