LISTEN Carefully: How NOTIFY Can Trip Up Your Database

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.