How does LISTEN/NOTIFY work under the hood

[adriangb]

I'm curious to learn a bit about how asyncpg, and maybe Postgres as well, implement LISTEN/NOTIFY. So far I know that:

• Listeners live as long as the connection (or as long as a connection is checked out from a pool).
• You can listen to multiple channels on a single connection
• Every new message triggers a call to the callback either directly (for sync callbacks) or in an asyncio task (for async callbacks)

I'm interested in learning more about how the data is transmitted. In particular, what the performance implications for postgres and asyncpg might be of transmitting 1,000 messages over 1 channel vs 1 message over 1000 channels (same number of messages).

I'd also like to better understand how listeners interact with regular queries. They're using the same socket, so obviously there might be some congestion and fighting for a lock, but are there other things to worry about aside from that? I also find it interesting that listeners have to be dropped when returning a connection to the connection pool. I thought that from Postgres' perspective listeners only need to be dropped when the connection itself is dropped? I realize it's still probably the right thing to do (if nothing else because LISTEN messes with transactions from what I gathered from the PG manual), but I am curious why it is how it is in asyncpg.

Thanks!