LISTEN Carefully: How NOTIFY Can Trip Up Your Database

POSETTE: An Event for Postgres 2026 is an online event for PostgreSQL, brought to us by the Postgres team at Microsoft, which took place on June 16-18, 2026. I'll always have a soft spot for in-person conferences, but POSETTE is probably the best-run online event in our community, and I was delighted to be invited back to speak.

As it happens, I had already given this same talk in person earlier the same month, at PG DATA 2026 in Chicago on June 4-5. My sincere thanks go to the organisers of both events for having me. The recording of my talk is now up.

If you use PostgreSQL's LISTEN and NOTIFY for asynchronous inter-process communication, they may be hiding a serious performance bottleneck in a high-throughput database. I walk through a real production incident where NOTIFY quietly brought a busy database to a grinding halt: how the internal serialisation of notifications triggers AccessExclusive lock cascades on pg_database, and how to architect a fix using unlogged queue tables, transaction-level advisory locks (pg_try_advisory_xact_lock), and batching to move NOTIFY out of your transaction hot path.

🎞️ Video on YouTube: youtube.com/watch?v=2-5WYY2bFjs

📊 View the slides: LISTEN Carefully: How NOTIFY Can Trip Up Your Database (PDF)

Have you been bitten by NOTIFY in production? I'd like to hear about it, on Mastodon at @vyruss@fosstodon.org or on Bluesky at @vyruss.org.