Uploaded June 2026 | Updated September 2026, 2 weeks ago
Understand how NOTIFY can impact your database under concurrency. Jimmy Angelakos (PostgreSQL Contributor) explains this in his talk “LISTEN Carefully: How NOTIFY Can Trip Up Your Database” at POSETTE: An Event for Postgres 2026. Abstract: LISTEN/NOTIFY is a powerful and elegant PostgreSQL feature for asynchronous communication between backend components. It allows lightweight data transfer and instant notification updates without the need for a separate message bus.
However, hidden within this simplicity and elegance is a surprising hazard: NOTIFY can cause unexpected statement and lock timeouts that seem to come out of nowhere. The reason for this is that each NOTIFY call obtains a cluster-wide exclusive lock to serialize notifications. Under high concurrency, seemingly innocuous code can end up causing performance bottlenecks and confusing backend errors—especially once traffic scales to levels difficult to replicate in development or on your laptop.
In this talk, we'll walk through a real-world scenario involving a trigger using NOTIFY to alert other systems LISTENing for changes made to a high-traffic table. We'll do a deep dive into the problems caused, the investigation of the symptoms, and a solution for fixing the issue in production.
You'll leave this talk equipped with an understanding of this wonderfully useful feature, along with its potential risks and what you can do to mitigate them.
Jimmy Angelakos is a Systems and Database Architect and recognized PostgreSQL expert who has worked with, and contributed to, Open-Source tools for 25+ years. He is passionate about participating in the community, is a Significant Contributor to the PostgreSQL project, and an active member of PostgreSQL Europe. Jimmy is a regular speaker at conferences and events, sharing his insights with the community. Author of PostgreSQL Mistakes and How to Avoid Them, co-author of PostgreSQL 16 Administration Cookbook.
► Video chapters:
⏩ 00:00 – Music & introduction
⏩ 00:53 – Speaker background and context
⏩ 01:35 – What LISTEN/NOTIFY actually does
⏩ 03:30 – How publisher-subscriber flow works
⏩ 06:36 – Production architecture with triggers and Redis
⏩ 08:07 – Symptoms: lock timeouts and query slowdowns
⏩ 10:02 – Root cause: global lock and accidental serialization
⏩ 13:17 – Initial fixes and why they failed
⏩ 14:43 – Queue-based async notification redesign
⏩ 18:12 – Advisory locks and batched notifications
⏩ 22:11 – Testing at scale and observed improvements
⏩ 24:39 – Key lessons and practical takeaways
📕 Everything you need to know about POSETTE: An Event for Postgres can be found at: posetteconf.com
✅ Learn more: watch more POSETTE talks: https://aka.ms/posette-playlist
📌 Let’s connect:
LinkedIn: linkedin.com/company/posetteconf
X – @PosetteConf, https://x.com/PosetteConf
Mastodon – @posetteconf, https://mastodon.social/@posetteconf
Bluesky – @posetteconf.com, https://aka.ms/posette-on-bluesky
#PosetteConf #PostgreSQL #database
Understand how NOTIFY can impact your database under concurrency. Jimmy Angelakos (PostgreSQL Contributor) explains this in his talk “LISTEN Carefully: How NOTIFY Can Trip Up Your Database” at POSETTE: An Event for Postgres 2026. Abstract: LISTEN/NOTIFY is a powerful and elegant PostgreSQL feature for asynchronous communication between backend components. It allows lightweight data transfer and instant notification updates without the need for a separate message bus.
However, hidden within this simplicity and elegance is a surprising hazard: NOTIFY can cause unexpected statement and lock timeouts that seem to come out of nowhere. The reason for this is that each NOTIFY call obtains a cluster-wide exclusive lock to serialize notifications. Under high concurrency, seemingly innocuous code can end up causing performance bottlenecks and confusing backend errors—especially once traffic scales to levels difficult to replicate in development or on your laptop.
In this talk, we'll walk through a real-world scenario involving a trigger using NOTIFY to alert other systems LISTENing for changes made to a high-traffic table. We'll do a deep dive into the problems caused, the investigation of the symptoms, and a solution for fixing the issue in production.
You'll leave this talk equipped with an understanding of this wonderfully useful feature, along with its potential risks and what you can do to mitigate them.
Jimmy Angelakos is a Systems and Database Architect and recognized PostgreSQL expert who has worked with, and contributed to, Open-Source tools for 25+ years. He is passionate about participating in the community, is a Significant Contributor to the PostgreSQL project, and an active member of PostgreSQL Europe. Jimmy is a regular speaker at conferences and events, sharing his insights with the community. Author of PostgreSQL Mistakes and How to Avoid Them, co-author of PostgreSQL 16 Administration Cookbook.
► Video chapters:
⏩ 00:00 – Music & introduction
⏩ 00:53 – Speaker background and context
⏩ 01:35 – What LISTEN/NOTIFY actually does
⏩ 03:30 – How publisher-subscriber flow works
⏩ 06:36 – Production architecture with triggers and Redis
⏩ 08:07 – Symptoms: lock timeouts and query slowdowns
⏩ 10:02 – Root cause: global lock and accidental serialization
⏩ 13:17 – Initial fixes and why they failed
⏩ 14:43 – Queue-based async notification redesign
⏩ 18:12 – Advisory locks and batched notifications
⏩ 22:11 – Testing at scale and observed improvements
⏩ 24:39 – Key lessons and practical takeaways
📕 Everything you need to know about POSETTE: An Event for Postgres can be found at: posetteconf.com
✅ Learn more: watch more POSETTE talks: https://aka.ms/posette-playlist
📌 Let’s connect:
LinkedIn: linkedin.com/company/posetteconf
X – @PosetteConf, https://x.com/PosetteConf
Mastodon – @posetteconf, https://mastodon.social/@posetteconf
Bluesky – @posetteconf.com, https://aka.ms/posette-on-bluesky
#PosetteConf #PostgreSQL #database
