NOTIFY/LISTEN and connection loss

Nobody has claimed this yet.

I need to watch data changes in multiple tables. One option is to add triggers and log changes to another table, which can be polled by the app every few seconds. A better option is to send PG notifications and set up a handler using `conn.add_listener()`. Do I need a dedicated connection for this approach, as opposed to a connection pool? How should I handle connection loss? If I kill a PG server process, asyncpg won't notice it either until TCP timeout (which can be very long) or until I try to execute another SQL command using the same connection object. Can you please provide a code snippet or a hint how to work with PG notifications more reliably?

Start with asyncpg's `conn.add_listener()` behavior and PostgreSQL LISTEN/NOTIFY connection-loss semantics. Determine whether a dedicated connection is required, how connection loss is detected, and what reliable reconnection guidance should cover. Done means the behavior and recommended handling are documented with a clear example or tested implementation.

Written by the indexing model from the issue text.